| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| jds2001 | j-rod: glad you showed up :) | |
|---|---|---|
| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod | |
| Hi everybody; who's around? | ||
| * nirik is here. | ||
| dwmw2 | fish | |
| * jds2001 loves giving folks a hard time | ||
| jds2001 here | ||
| dwmw2 | oh | |
| * Kick__ is here | ||
| f13 | ||
| j-rod | finally made it on time for once | |
| * dgilmore | ||
| dwmw2 would like to request Sponsor status | ||
| * wwoods lurking while in another meeting | ||
| dwmw2 | I went to sponsor someone and realised I couldn't :) | |
| * notting is here | ||
| bpepple | dwmw2: we usually send the requests to the list for feedback from the community, but I can't remember if we've done that with FESCo members or not. | |
| dgilmore | dwmw2: denied | |
| dwmw2 | dgilmore: I know where you live | |
| jds2001 | dwmw2: that surprises me, while we're at sponsor requests, throw my name in there | |
| jeremy | bpepple: we have | |
| * nirik nods. We should follow the same procedure for anyone. ;) | ||
| jds2001 | bpepple and I talked about it at OLF, but never made it a formal request I guess :) | |
| dwmw2 | next week then | |
| * jds2001 nods | ||
| bpepple | ok, so dwmw2 how about I send your (and I assume jds2001 request) to the list, and we vote on them at the next meeting. | |
| dwmw2 | ok | |
| jds2001 | sure | |
| bpepple | ok, so let's get started since we got a bunch of items on this week's agenda. | |
| --- bpepple has changed the topic to: FESCo-Meeting - F11/F12 Schedule - https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html - f13, all | ||
| bpepple | f13: you want to lead on this? | |
| f13 | Sure. | |
| f13 | Basically my first mail lays it all out there, and what I'm looking for from fesco is agreement on a target end date for F11, and a less set in stone idea about what to do for F12 | |
| f13 | once those are picked out, or at least the F11 end date, releng (poelstra) can work on a full fledged schedule for F11 with all the internal date points for FESCo approval. | |
| dgilmore | f13: so that would give us 6 months for F-11 and 5 months for F-12 | |
| f13 | that is correct | |
| nirik | so it's a 1 month shift of or normal, then back on track after f12? | |
| f13 | I understand there are some concerns about slip potential, and I have some plans for some intra-schedule adjustments to help that | |
| nirik: yes | ||
| dgilmore | i think im ok with this. the other acceptable option would be splitting the two and doing middle of may release of F-11 | |
| bpepple | f13: yeah, that's my only concern about reducing the devel time for f12, since we have less wiggle-room due to the holidays. | |
| jeremy | f13: I have very strong concerns about slip potential | |
| dgilmore | i do think we need to push F-11 out some | |
| jds2001 | f13: what intra-schedule adjustments are you comtemplating? | |
| f13 | jeremy: I know you do, and you've voiced them well on list. | |
| wwoods | dgilmore: you want it to be *longer* than a normal schedule? | |
| dgilmore | wwoods: no. | |
| f13 | jds2001: I'm proposing moving the feature freeze date a week back from the actual beta freeze, to give us a week of integration fixups | |
| dgilmore | wwoods: either what f13 is proposing or middle of may F-11 release | |
| jeremy | f13: while I appreciate we're putting new things to try to help things which have led to slips in the past, we do that with some frequency. yet slips are remarkably consistent over the entire life of fedora releases | |
| f13 | jds2001: I'm also proposing that certain key software packages "feature" freeze even earlier than that, so that they are focused on adjusting for any last minute other feature changes rather than scrambling to finish their features. | |
| jds2001: things like kernel, anaconda, compose tools | ||
| jds2001 | that makes sense, anaconda always kills us for various reasons :) | |
| f13 | jeremy: that is correct, they are consistant in the amount of about a week, or two total. | |
| pjones | f13: that proposal kindof blows though, since our features are generally dependent on features in other parts of the distro. | |
| jeremy | f13: incorrect sir. | |
| notting | jeremy: how so? most of f10's slip is a non-predictive event, of course | |
| pjones | jeremy: what's the standard deviation on our slip time? | |
| jeremy | the mean is basically 3 weeks, standard deviation was a week or so | |
| f13 | pjones: which can be considered on a release by release basis, and I am just proposing, looking for input, I'm not dictating as that would really really blow. | |
| jeremy | notting: most of every single slip we've had has been non-predictive | |
| pjones | f13: understood. | |
| jwb_gone | i'm here | |
| pjones | f13: all I'm saying is, it has a significant downside. | |
| notting | jeremy: f10 is different. | |
| there may always be broken software or features. there is unlikely to be a 3-week infrastructure blackout again | ||
| f13 | pjones: nod, it's the more contentious proposal too. | |
| jeremy | notting: the infrastructure blackout didn't stop work from occurring upstream. you can't just disregard that time. if anything, you throw out the data point entirely, but it didn't really make a substantial change to the data | |
| f13 | pjones: maybe not one that can be enumerated in an ongoing rule, but instead investigated per-release. | |
| pjones | notting: I wouldn't agree with that. It's unlikely that it'll be for the same reason, but to me it seems very much like the sort of thing that'll recur on a longer cycle. | |
| jeremy | the two largest slips in history were fc6 and fedora 7, each being somewhere between 5 and 6 weeks off from their original schedules | |
| pjones | jeremy: eh, the infrastructure blackout very much did stop work from occurring upstream. | |
| f13 | it also stopped the work upstream from being consumed in the Fedora downstream | |
| jeremy | pjones: really? kernel development stopped? gnome development stopped? | |
| dwmw2 | and integrated and tested | |
| dgilmore | jeremy: F-7 was largely due to the merge taking so long to complete | |
| jeremy | f13: it had some impact, but you can't just presume it was 1:1 | |
| f13 | jeremy: of course not | |
| dgilmore | i forget why FC-6 slipped | |
| jeremy | dgilmore: I can come up with rationalization for every single slip we've had, that's not the point | |
| f13 | jeremy: wasn't it you though that keeps saying we can't plan for slips? | |
| pjones | jeremy: no, but anaconda slowed severely, and the network-manager changes associated with it did as well. And those aren't negligible. | |
| jeremy | and most of them are unpredictable "thing that had big impact" + then the nominal 1-2 weeks we always seem to get screwed by :/ | |
| dgilmore | jeremy: sure. we cant antipipate every thing that will cause need for slipping | |
| jeremy | f13: you can't plan for them, but when looking at your future, you have to take htem into your risk analysis | |
| f13 | jeremy: I think we are. | |
| jeremy | we chose may 1st and oct 31st because they both give us the window to get back on track and not run into the holiday time of doom | |
| f13 | there is risk to sipping F11 to the date that we're proposing anyway, given the amount of stuff that is likely to be poured into it for RHEL | |
| stickster | The holiday problem is almost entirely on the autumn release, not the May one. | |
| f13 | there is risk that F12 will suffer, but that's also something we can take into account when setting the schedule for F12 | |
| dgilmore | stickster: there is memorial day in may | |
| jeremy | stickster: yes. but we account for that by trying to pull the spring release back to where it "should" be | |
| jds2001 | dgilmore: i don't go back to STL for memorial day, for example | |
| dgilmore: but I am for thanksgiving | ||
| I think that sort of travel is what we mean by "doom" :) | ||
| dgilmore | jds2001: sure thanksgiving is the most disruptive outside of Christmas | |
| jeremy | f13: the problem is that's then too late... if f11 is even just the second week of june, then we're to a 4.5 month cycle for f12. or scheduling it to coincide with the holidays | |
| * dgilmore notes that he will be in .au may 2 - 23 | ||
| dgilmore | jeremy: or slipping until January | |
| notting | jeremy: and i think that lopping an entire month off the schedule is a non-starter. so, you're in essence saying that dates are more important than time-based | |
| f13 | jeremy: so what is your alternate proposal? | |
| jeremy | dgilmore: at which point, we're entirely off the may/october bandwagon | |
| f13: I laid out two alternate proposals on the thread. #1) the tuesday close to may 1st as we've always said we'll do #2) if we think that there are _crucial features_ for f11, then let's get their schedules up and set f11 up as a feature based release | ||
| dwmw2 | are there particular reasons for wanting to stick to may/october? | |
| caillon | there are other bandwagons in the lot which are nice, too. like the august/feb one | |
| dgilmore | f13: i kinda like staying with oct 27 but doing may 12 or 19 | |
| dwmw2 | I heard some discussion about wanting to make it _earlier_ than that | |
| jeremy | notting: we've done it before. the 5 month release was only off by a week for f8 | |
| j-rod | I think the 5 month target would normally be fine and dandy, if not for the huge elephant in the room | |
| (RHEL6) | ||
| jds2001 | but lopping 6 weeks off is a problem. | |
| j-rod: this proposal is designed to cater to the huge elephant, I thought :) | ||
| j-rod | exactly | |
| f13 | if we can. | |
| stickster | It's designed to split the difference between catering and ignoring, I think. | |
| jeremy | caillon: august/feb kind of sucks, though too. it puts beta for feb right around the holidays and it means we release right before the desktop release | |
| f13 | by no means is this a "strong arm" move by Red Hat to try and force the Fedora schedule. | |
| jwb_gone | does anyone thing it's a bad idea to cater to RHEL6 here? | |
| notting | fedora elephant catering steering committee. it even fits! | |
| bpepple | notting: ;) | |
| wwoods | we have to drop a month *somewhere* | |
| bpepple | wwoods: can we drop 2 weeks for f11 & f12? | |
| wwoods | so if we do it in such a way that we can get the full force of RHEL engineering aligned with us and working on Fedora, so much the better | |
| jds2001 | that's exactly what I was thinking wwoods | |
| nirik | wwoods: do we know what that would require? | |
| (ie, which schedule)? | ||
| jds2001 | however, in full disclosure, I'm a RHEL customer too.....so I have a vested interest in RHEL6 being great :) | |
| jds2001 | and that starts in Fedora, and getting engineering resources aligned with us. | |
| stickster | jds2001: I think everyone who's in Fedora has _some_ vested interest in that | |
| bpepple | ok, we've spent about 25 minutes on this, could I get a quick show of hands on f13's proposal to see where we are? | |
| caillon | jeremy: true, just saying that may/oct is mostly a historical 6month period. it was chosen in part because of where we were at the end of a past release cycle. thought should be given if it still makes sense. | |
| dwmw2 | +1 | |
| jwb_gone | +1 | |
| jds2001 | +1 | |
| j-rod | +1 | |
| Kick__ | +1 | |
| bpepple | 0 | |
| jeremy | caillon: a lot of time actually went into getting there. it was not a fun time :/ | |
| * nirik doesn't have a lot of strong feeling on it. Either f13's or stick to our normal dates. | ||
| nirik | so, I guess +1 | |
| notting_ | sorry, kernel panic. dropped off ater 'bpepple: wwoods: can we drop 2 weeks' ... | |
| dgilmore | +1, though i think id prefer shaving a week or two off of F-11's schedule | |
| jwb_gone | bpepple, we have 7. f13's schedule passed | |
| bpepple | so, I see seven '+1', and one '0' to f13's schedule proposal. so | |
| it's passed. | ||
| nirik | notting_: that doesn't sound good right before release... hopefully you were using some weird test kernel thats not in rawhide? :) | |
| notting_ | nope | |
| wwoods | notting_: i945 random-lockup funtime? | |
| * hadess wonders when we speak about features, because that's why he's here | ||
| bpepple | f13: is there anything else regarding the schedule we need to look at? | |
| hadess: features are the next item on the agenda. | ||
| notting_ | bpepple: for the record, i'm +1 to f13's proposal, but amenable to splitting the difference if it makes people happy | |
| f13 | bpepple: not today, we'll come back in a week or so with a full schedule for final approval. | |
| bpepple | f13: ok, thanks. | |
| alright, let's move on to features now, unless anyone has anything else to add about the schedule. | ||
| moving on..... | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/DeviceKit | ||
| mccann | just a drive by comment, but it would be good to keep this in mind: http://live.gnome.org/TwoPointTwentyfive/ | |
| bpepple | hughsie: ping. | |
| hughsie | bpepple: pong | |
| bpepple | where getting ready to discuss your feature. | |
| hughsie | okay, want me to introduce it? | |
| bpepple | s/where/we're/ | |
| nirik | mccann: I think thats one of the reasons we moved to the two dates we have... sync with gnome, possibly other upstream projects. | |
| bpepple | hughsie: yup, that would be fine. | |
| hughsie | bpepple: well, put bluntly HAL upstream is pretty dead | |
| hughsie | the replacement is a series of daemons called DeviceKit | |
| each one quite specialist to avoid bloat | ||
| each one system activated so it only loads when needed | ||
| the main one, DeviceKit is a simple wrapper over udev | ||
| this allows other daemons such as DeviceKit-power and DeviceKit-Disks to be implemented | ||
| DeviceKit-disks is a clever daemon that lets you submit jobs to do things with disks | ||
| dwmw2 | does this help to fix the startup time problems we have with udev? | |
| hughsie | for instance, create raid arrays using a nice GUI tool | |
| dwmw2 | or is that separate? | |
| jwb_gone | so DeviceKit basically does udev<->dbus enablement? | |
| notting | dwmw2: no, not really | |
| hughsie | dwmw2: well, it means we only do the coldplugging once, in udev, in parallel | |
| notting | dwmw2: if we can eventually killoff hal, will fix startup times with that | |
| hughsie | doing it in series in HAL means we can take several minutes to start haldaemon on a box with lots of disks | |
| * nirik notes thats a long list of hal using things... I guess the wrapper would mean many of them wouldn't need to change right away. | ||
| hughsie | DeviceKit-power is a fairl thick wrapper to let the user have accurate time profiling and latency control on all sessions | |
| jds2001 | i dont think the proposal is to kill hal right now, right? | |
| hughsie | latency control alllows us to do agressive power management and not have a sluggish desktop | |
| jds2001 | just put scaffolding in to allow us to do so in the future? | |
| hughsie | no! | |
| hal will be arond, although depricated | ||
| new development is DeviceKit | ||
| jwb_gone | so DeviceKit basically does udev<->dbus enablement? | |
| dwmw2 | so all the packages which currently provide .fdi files will be expected to change? | |
| hughsie | so during F10, I'll try to port as much stuff to DK-p as I can | |
| dwmw2 | admittedly, I have no clue how many that is ;) | |
| * nirik wonders if KDE/Xfce/etc know about this, and are ok with moving to it? | ||
| hughsie | dwmw2: no, for the moment they can stay -- davidz is working on udev replacment | |
| dwmw2 | ok | |
| hughsie | dwmw2: a lot of an fdi file you can do in a udev rule, in parallel | |
| so it's much quicker | ||
| jwb_gone | hughsie, so DeviceKit basically does udev<->dbus enablement? | |
| hughsie | KDE can trivially move to DK-p and DK-d as they use SOLID. | |
| jwb_gone: yup, the low level device enumeration | ||
| DeviceKit is pretty much feature complete now | ||
| jwb_gone | hughsie, so why don't you just add dbus hooks to udev? | |
| hughsie | it's the -daemons that need the work | |
| jwb_gone: wrong level | ||
| jwb_gone | wrong level how? | |
| hughsie | jwb_gone: udev starts waaaay earlier. | |
| jwb_gone | oh | |
| hm | ||
| yeah, maybe | ||
| bpepple | +1 here to DeviceKit feature. | |
| hughsie | the latency bits may be contriversial | |
| notting | +1 | |
| nirik | +1 | |
| jwb_gone | as long as i don't even notice it exists, +1 | |
| dgilmore | +1 | |
| notting | jwb_gone: too late, you know now! | |
| bpepple | ok, I see five '+1' to this feature, and no objections, so we have approved it. | |
| j-rod | +1 | |
| jwb_gone | notting, i said noticed, not know | |
| jds2001 | +1 for the record :) | |
| jwb_gone | er, notice | |
| hughsie | col | |
| cool | ||
| bpepple | Thanks, hughsie. | |
| dwmw2 | +1 | |
| bpepple | anyone, have anything else to add about DeviceKit? Otherwise we can move on to the next feature. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/VolumeControl | ||
| bpepple | hadess: ping. | |
| hadess | yes | |
| what about it | ||
| wwoods | is there a roadmap for converting .fdi files to udev equivalents? documentation to help maintainers move their packages away from libhal? | |
| hughsie | wwoods: not yet, davidz still has to talk to kay | |
| dwmw2 | we'd still have access to the individual mixers, right? | |
| it's always a pain to work out which one does what, on new hardware. | ||
| no fscking way we want to trust that to magic | ||
| where it works, great | ||
| hadess | dwmw2: that replaces gnome-volume-control, and uses pulseaudio | |
| dwmw2 | but don't take away my ability to turn on _every_ bloody mixer on the device and fuck with them till I find a way to make the damn thing actually make noise | |
| notting | dwmw2: iow, work around broken kernel? | |
| hadess | well, you can use alsamixer if you want that | |
| dwmw2 | pulseaudio is the thing I have to kill to get audio working, right? :) | |
| hadess | or KDE | |
| hadess | dwmw2: if your setup is that broken, yes | |
| dwmw2 | does a clean Fedora install on my MBP.count as broken? | |
| notting | is random bugs in one of kernel, alsa, or PA the point of this feature? | |
| bpepple | wwoods: are the test plans for the volume control feature sufficient for the qa team? | |
| dwmw2 | notting: only if we are being denied the ability to work around them :) | |
| wwoods | bpepple: test plans are non-present, although the use case / user-experience stuff is well done | |
| jds2001 | I'm still unclear on how to actually use the thing. | |
| nirik | so this is a new super sound pref app... gnome specific I guess? as long as other things keep working, (pavucontrol, alsamixer) this sounds fine. | |
| jds2001 | (from a QA perspective, that is) | |
| bpepple | wwoods: that's what I was wondering. I was sure if the use cases were enough for you guys or not. | |
| wwoods | they're not. | |
| notting | it's not like you can break alsamixer w/o effort | |
| notting | there's no way this could | |
| jds2001 | for example: Michael realises that his builtin speakers are too teeny anyway, so wants to only play sound effects at a low volume on them, and keep on playing music through the bigger USB speakers. If the USB speakers were to come unplugged, the sound would go back to the internal speakers. Replugging them would get them their music back. | |
| How do I effect that behavior? | ||
| wwoods | I have a clear idea of *why* I want this now, but not how to confirm that the code matches the specification | |
| hadess | right now, there's practically no code | |
| * nirik notes after the horror of the openmoko alsa setup, simple sound adjustment sounds like a very good thing to me. | ||
| hadess | mccann: ? | |
| dwmw2 | nirik: :) | |
| wwoods | Scope gives me a rough outline of the spec | |
| jds2001 | oh, well that's a good reason not to know how to do it :) | |
| (there being no code) | ||
| mccann | hadess: oh it's you | |
| hadess | mccann: talking about your code now | |
| mccann: volume control stuff | ||
| wwoods | but yeah, it'd be really helpful if the Scope was more detailed about what the expected changes are | |
| bpepple | hadess: the feature looks good to me, but I think we need to provide a test plan for the qa folks before approving this feature. | |
| wwoods | the Test Plan kind of flows from there - if you have a list of changes, writing instructions on testing those changes is usually pretty straightforward | |
| mccann | hadess: have you tried it yet? | |
| hadess | bpepple: too early for that | |
| hadess | mccann: people are discussing it on usability-list as well | |
| bpepple | hadess: ok. | |
| mccann | yeah i saw that | |
| dgilmore | how will this effect KDE, and XFCE? | |
| notting | it won't | |
| hadess | i didn't see your latest code yet | |
| nirik | dgilmore: not at all it sounds like. | |
| dgilmore | :( | |
| ok | ||
| bpepple | alright, so I'm +1 to this feature, but I concerned about approving it without a test plan for QA. | |
| notting | yeah, +1 with the 'need a test plan by feature freeze' caveat | |
| * nirik nods. Or hopefully sooner. | ||
| j-rod | sure, why not | |
| as long as I can still get at all the knobs via some route, +1 | ||
| (and/or, everything Just Works) | ||
| dgilmore | im 0 for now | |
| hadess | fwiw, it will get into gnome 2.26 anyway | |
| dgilmore | i think we need to know a test plan, which include making sure that KDE, XFCE dont have regressions due to the changes | |
| jds2001 | +1 with a test plan by feature freeze or we drop it. | |
| bpepple | nirik, kick_: ? | |
| hadess | so it'll get in through upstream | |
| notting | i don't see how kde/xfce/etc can have regressions from gnome adding a panel/notification area applet | |
| nirik | yeah, I don't think there would be any... | |
| jds2001 | actually i'd prefer a test plan by alpha really | |
| dgilmore | notting: so all of the underlying system work is complete? | |
| Kick__ | +1 from me | |
| notting | dgilmore: according to the page, the PA stuff is | |
| wwoods | jds2001: how about a *spec* by Alpha, test plan by Feature Freeze | |
| jds2001 | dgilmore: there isn't any, I don't think..... | |
| nirik | +1 with test plan as soon as they can... but before feature freeze in any case. | |
| dgilmore | notting: ok. i was assuming there was low level changes needed | |
| bpepple | alright, I see six '+1', and one '0', with the caveat that a test plan is provided before feature freeze. | |
| so, this feature has been approved. | ||
| jds2001 | wwoods: sounds good :) | |
| dwmw2 | 0 | |
| bpepple | anyone, have anything else to add? otherwise we can move on. | |
| thanks, hadess & mccann. | ||
| topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Windows_cross_compiler | ||
| rwmjones | good evening | |
| hadess | pleasure | |
| notting | rwmjones: technically, your two benefits are for fedora the project, not fedora users | |
| bpepple | rwmjones: this feature is going to require that all those minGW packages in the queue get reviewed right? | |
| rwmjones | notting, I think they're for fedora users-who-are-developers, ie. that subset of fedora users | |
| rwmjones | bpepple, yes, there's a mammoth list, 50 or so IIRC | |
| nirik | rwmjones: under scope it says you must use your repo... surely those things should be all in the main repo for this feature, right? | |
| rwmjones | nirik, yes, they should be in the main repository | |
| wwoods | there was a looong argument about that the last time around, wasn't there? | |
| rwmjones | wwoods, that's different | |
| wwoods, we're using a temporary repository for testing right now | ||
| * nirik just doesn't think the feature we tout should require/mention another repo. | ||
| rwmjones | but the aim is to get all the libs & dev tools into Fedora | |
| notting | i think we should invite some cygwin people to comment. >:) | |
| rwmjones | the exceptions are applications which stay outside Fedora, but testers might wish to build them | |
| notting | more seriously, i agree with nirik | |
| nirik | rwmjones: can you modify that to mention that you can test via that repo, but they will all be in for the feature? | |
| wwoods | ah | |
| rwmjones | nirik, oh maybe it's not very clear, but yes you are right it needs to be clarified | |
| * jds2001 confused | ||
| jds2001 | what's the difference between this and the MinGW feature last time around? | |
| bpepple | rwmjones: maybe a link to the mingw packages in the queu or something. | |
| nirik | jds2001: this is touting using wine and using the mingw feature from last time. | |
| jds2001 | is this just getting more libraries in? | |
| OK | ||
| rwmjones | https://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32 ... so far .. there are more which I haven't made up RR's for yet | |
| jds2001, well this is hopefully to get a feature into the release notes | ||
| nirik | rwmjones: also if you could possibly mention which reviews are more important than others? I'd be happy to do some, if you can blast me an email or give me a list of important ones... | |
| jds2001 | OK, that makes sense. | |
| rwmjones | nirik, from the top downwards | |
| nirik | rwmjones: ok. cool. | |
| rwmjones | nirik, basically gcc, w32api & runtime are essential, then follow the remaining libraries downwards as they are roughtly in dependency order | |
| nirik | rwmjones: ok. | |
| rwmjones | nirik, but I've been careful to set the bugzilla dependencies correctly :-) | |
| nirik | is there any problem using "Windows" here? didn't MS trademark it? | |
| --- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Windows_cross_compiler | ||
| rwmjones | nirik, well hmmm I hadn't thought about that actually | |
| nirik | http://www.microsoft.com/about/legal/trademarks/usage/windows.mspx | |
| rwmjones | maybe spot can comment? | |
| notting | we'll just have to hit a buzzer every time justin long mentions the feature | |
| bpepple | +1 to Window cross compiler feature. | |
| nirik | also, which windows(tm) versions are we talking here? I guess anything wine can emulate? | |
| j-rod | +1 | |
| rwmjones | nirik, yes basically ... | |
| dgilmore | +1 | |
| nirik | might note that on the feature page... | |
| +1 here. | ||
| jds2001 | +1 | |
| rwmjones | anything with the win32 api ... which MS are trying to deprecate because wine've done such a good job of reimplementing it | |
| bpepple | ok, I see five '+1', and no objections, so we've approved this feature. | |
| wwoods | It's a trademark but a) fair use and b) their trademark guidelines specifically allow its use in "a referential phrase such as 'Windows XP'" | |
| rwmjones | ok thanks everyone ... if you have questions outside the meeting please email me rjones ... redhat ... com | |
| dwmw2 | +1 | |
| che_ | nirik, xp 2000 2003 2008 vista 95 98 2000 nt 3.5 nt 4 win2.0 win3.0 win3.1 | |
| bpepple | rwmjones: since this feature is dependent on package reviews maybe we can try to schedule some reviews days to get a coordinated effort on it. | |
| nirik | che: ok. | |
| Kick__ | a late +1 from me, I've lost keyboard input and had to resdtart | |
| rwmjones | bpepple, I would love people to review these packages :-) | |
| nirik | bpepple: +1. Good idea. | |
| * jds2001 can throw a hand in too | ||
| bpepple | ok, anyone have anything else they wish to add before moving on to the next feature? | |
| nirik | rwmjones: your bugzilla search picks up some unrelated bugs at the end there. ;) | |
| bpepple | alright, moving on....... | |
| --- bpepple has changed the topic to: FESCO-Meeting -- Features -- pushed from F10 to F11 https://fedoraproject.org/wiki/Features/Presto -- everything still relevant? | ||
| bpepple | lmacken: ping. | |
| lmacken | Ok | |
| lmacken | So, as agreed upon by FESCo a while back, Presto will not be an official F10 feature. However, we will be trying to roll it out during the F10 timeframe, and announce it as an optional feature. | |
| lmacken | If all goes well, and we get plenty of testing, this should be a solid F11 feature. | |
| che | lmacken, thats great. | |
| lmacken | I'm going to be working with skvidal and jdieter to streamline the deltarpm generation and integrate it with our updates process. Seth will be tackling this up from a createrepo angle, and I will be helping with the bodhi integration. | |
| che: indeed | ||
| j-rod | +1, been looking forward to it for a while | |
| che | maybe it would also be about time to build a 64bit wine | |
| notting | +1 | |
| jds2001 | +1 | |
| nirik | would rpm switching to the lzma compression affect this any? are we thinking of doing that in F11? | |
| dwmw2 | +1 | |
| lmacken | nirik: I haven't the slightest clue. That's a seth/panu question | |
| bpepple | +1 | |
| * jds2001 didnt know anything about rpm switching compression. | ||
| dgilmore | +1 to Presto | |
| nirik | +1 to presto in any case... just wondering on that | |
| notting | nirik: AIUI, it's more or less a binary diff. if lzma does something odd that makes it less diff-able, it will affect it | |
| bpepple | alright, that's seven '+1', and no objections so we've approved this feature for F11. | |
| Kick__ | why do we decide on it if the maintainers don't think it is a feature ? | |
| jds2001 | Kick__: it will be a feature for F11 | |
| so it is a feature :) | ||
| nirik | Kick__: with what? Presto? | |
| Kick__ | presto, yes | |
| jds2001 | we decided to punt to F11 last time around. | |
| Kick__ | sorry , didn't get it... It is in F10 as a non-feature, but will be a feature in F11 | |
| +1, then | ||
| bpepple | Kick_: yeah, it was a feature preview for F10, since we can't really test it with rawhide. | |
| anyone have any other questions about Presto? | ||
| lmacken: thanks! | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- Features --https://fedoraproject.org/wiki/Features/Multiseat | ||
| bpepple | ctyler: ping. | |
| dgilmore | Kick__: yeah it needs a release cycle of being used for propper testing | |
| ctyler | Multiseat refers to having multiple users using one computer, via several sets of monitor/keyboard/pointing device[/speakers]. It can save a lot in terms of hardware, electricity, and admin effort compared to running multiple systems. | |
| * jds2001 notes the test plan is, um, lacking. | ||
| ctyler | Five years ago, this required major patches to the kernel and to X. By Fedora 8, multiseat systems could be configured by editing the GDM and X configuration files. However, X and GDM changes in F9 made it unusable for multiseat operation. Multiseat users are now facing EOL on F8. | |
| What I'm proposing is making multiseat easy to configure on F11. This involves fixing the regressions in GDM and X (upstream has patches) and either using MDM (multiseat display manager, which is a misnomer as it uses GDM) or extending ConsoleKit to be multiseat aware. | ||
| mccann | hi ctyler | |
| jds2001 | ctyler: looks great - how do I test it? :) | |
| * jds2001 notes "get hardware and configure" is not suffcient :) | ||
| ctyler | TBH, without the hardware, you can't really test multiseat. | |
| * nirik likes the idea a lot, but it's going to be a lot of work it looks like. ;) | ||
| jds2001 | right, say I had the hardware | |
| * jds2001 sees nothing in there about how to configure said hardware | ||
| nirik | also notes about what hardware works would be very nice... ie, what video cards live together, etc? | |
| notting | i suppose it depends on what's done in CK/gdm - that would change how it's configured | |
| ctyler | If we go the MDM route -- which I'm favoring -- you will need to configure a backend that matches your setup (multicards, or one card multi output), and fire it up | |
| To this point, i.e., F8, it's all been manual config. MDM or CK could change that for the better. | ||
| I think the minimum I'd like to see is to get things fixed back up so manual config works. MDM is an easy next step past that. | ||
| ctyler | The patches for the X regressions and removed functionality in GDM are upstream. | |
| notting | ctyler: how do you handle X w/evdev? | |
| ajax | presumably, by extending X to know what seat it's on | |
| mccann | we really should put our efforts into adding device support to CK | |
| ajax | and tagging evdev devices in hal with what seat they belong to | |
| ctyler | until F9, evdev config in x.org let you match input devices with displays. There's a keyword to turn off the hotplug stuff, but that needs testing. | |
| That would be ideal, yes. | ||
| notting | ajax: devicekit-input *runs* | |
| nirik | notting: InputKit ? | |
| mccann | no, ConsoleKit | |
| nirik | so, can we approve this as it stands? or should we perhaps see if the test plans and hardware can be updated first? | |
| bpepple | wwoods: thoughts? | |
| mccann | ctyler: see slide 43 of http://www.gnome.org/~mccann/talks/guadec-new-gdm-turns-you-on.pdf | |
| notting | this feature seems to boil down to 'lock ctyler and mccann into a room to flesh it out' | |
| halfline | fwiw, getting multiseat right in consolekit and gdm has been a todo item for a while | |
| bpepple | notting: ;) | |
| wwoods | bpepple: "work with QA to test" is not a test plan | |
| * jds2001 noted the previous two items didn't comprise a test plan either :) | ||
| wwoods | scope looks pretty good for a spec, though | |
| jds2001 | I'm not sure it's really fair that we harp on test plans this early, tbh | |
| but we need to at some point. | ||
| at each milestone (alpha, feature freeze) we should come back to it, IMO | ||
| bpepple | alright, so a common theme on features seems to be that the test plans tend to be a bit on the thin side (if there at all). What can we do to fix that? | |
| nirik | well, but we don't want to approve now and then realize there was never a test plan. | |
| wwoods | serialize some of the tasks - rather than "you need scope, test plan, etc.. ASAP" | |
| jds2001 | true as well | |
| wwoods | require a fleshed-out scope by Alpha | |
| and then a Test Plan written from that happens between Alpha and Beta (or Feature Freeze) | ||
| bpepple | wwoods: that sounds good to me. | |
| wwoods | which means that fesco "approval" needs to happen at each stage | |
| wwoods | but that's the de-facto procedure anyway | |
| bpepple | wwoods: agreed. | |
| * dgilmore really likes the idea of multiseat | ||
| notting | means we'll be busy | |
| bpepple | notting: yeah. | |
| halfline | just want to reiterate that multiseat has been a concern since consolekit's inception. it needs work, but the work should go there | |
| wwoods | should mean less confusion at each feature-approval session though | |
| bpepple | Does anyone object to wwoods proposal? | |
| jds2001 | but is there any other way to do it, though? | |
| wwoods | since each feature will have distinct phases it must go through | |
| jds2001 | +1 to wwoods proposal | |
| wwoods | it'd be more obvious whether or not the feature is in the right phase | |
| jds2001 | having difficulties today notting_ ? :/ | |
| bpepple | +1 to multiseat feature, based on wwood's proposal. | |
| notting_ | i love the kernel, it is my friend | |
| Kick__ | +1 (wwoods proposal) | |
| dgilmore | +1 | |
| dwmw2 | +1 | |
| j-rod | +1, ditto bpepple | |
| f13 | wow, meeting still going! | |
| nirik | +1 here too | |
| dgilmore | f13: we are planning to make lots of work for F-11 | |
| :) | ||
| bpepple | ok, I see six '+1', and no objections to the multiseat feature, so it's been approved. | |
| wwoods | if we need better guidelines for what constitutes a good Spec (Scope, Blueprint, Roadmap, whatever) I'll be happy to advise | |
| * dgilmore hates having two meetings at once | ||
| jds2001 | f13: that's why we extended the meetings to 2 hours | |
| jds2001 | :) | |
| ctyler | thanks! | |
| f13 | ah. | |
| glad we gave F11 more time to get done (: | ||
| bpepple | ctyler: thanks for your time. | |
| halfline | ctyler: do find mccann and talk to him | |
| ctyler | halfline: for sure :-) | |
| halfline | ctyler: so there isn't any overlap in what you two are doing | |
| bpepple | ok, that's all poelcat had for us on features this week. so unless there is anything else regarding features we can move on. | |
| --- bpepple has changed the topic to: FESCo-Meeting - https://bugzilla.redhat.com/show_bug.cgi?id=472061 - all | ||
| bpepple | kick_: you wanted to discuss this. | |
| jds2001 | i looked into this, everyone knows I'm not a desktop guy | |
| Kick__ | That's a bug that popped up several times and I think this can get us into trouble | |
| jds2001 | I just leave stuff in the default config for the most part on my desktop | |
| nirik | it's been removed a bunch of times. | |
| jds2001 | and there's no pr0n in the default config (I use GNOME and Xfce on different machines) | |
| or even potential for it. | ||
| Kick__ | imagine you start the screensaver to lock out your kids, come back and see some porn on the screen | |
| nirik | it just grabs images from the net. It doesn't care what they are. | |
| dgilmore | jds2001: its random seaches exlicitly have censorship turned off | |
| Kick__ | jds2001: you just have to select 'random screensaver' or even wors 'webcollage' | |
| bpepple | Kick_: is there anything else we can do, other than patch out the behavior like we have in the past. | |
| notting_ | so... how did it get added back? | |
| f13 | I think in the past ti's been worked around by the callers, like the kde screensaver caller | |
| jds2001 | Kick__: no doubt | |
| f13 | it wasn't never fixed in the package itself | |
| notting_ | f13: it was explicitly removed from the list of 'random' screensavers in xscreensaver. not sure if kde/gnome use that | |
| f13 | and it seems the maintainer doesn't want to fix it in the package? Not sure here. | |
| dgilmore | bpepple: i think that we need to work with upstream add configuration checkboxes to turn on or off filering of results. defaulting to filtered results | |
| jds2001 | yeah, this sounds like something more for upstream | |
| Kick__ | Than Ngo told me that upstream refused the patch we had for this | |
| halfline | notting_: iirc jwz made the source of images configurable | |
| * notting_ rofl | ||
| jds2001 | dgilmore: +1 | |
| notting_ | yeah, we're not going to get jwz to change the upstream defaults | |
| abadger1999 | f13: It looks like the packager fixed it this time? | |
| dgilmore | notting_: upstream could default to unfiltered | |
| nirik | yes, it's fixed by the packager. | |
| nirik | they added a wrapper. | |
| dgilmore | notting_: and we can patch it to the other | |
| f13 | yeah, I'm not sure the status now with the wrapper | |
| I couldn't tell if it defaults to safe or unsafe | ||
| * nirik looks. | ||
| notting_ | realistically - it should not be in the random list, and kde/gnome/etc can just not use it? | |
| Kick__ | f13: just start webcollage and see what happens. It took 10secs on my machine to display some X-rated stuff. I'd say the defaults aren't safe at all | |
| nirik | ok, by default it looks at backgrounds locally (no net), but the orig one is available as webcollege.orig if you want to enable it (disabled by default) | |
| dwmw2 | how does it find imageS? | |
| dgilmore | dwmw2: randmom pulls from nytimes.com altavista.com and ircimages.com | |
| i guess its pulling a page that returns top images queried or some such | ||
| nirik | look in /usr/libexec/xscreensaver/webcollage it's a perl script. | |
| it pulls from a ton of image sites. | ||
| * dgilmore walked in at work in the past and it was up. | ||
| dgilmore wasnt happy, and learnt to turn random screensaver off after that | ||
| nirik | Kick__: the fixed one is not in rawhide/F10 final. | |
| I suspect it got re-enabled on a rebase to upstream sometime, as it was off before. | ||
| notting_ | nirik: how recently? was it this way in F9? (note: mtasaka tends to be a push new-release-everywhere person) | |
| nirik | Dunno... I guess we can look back and try and see... | |
| it was removed in 2004 by than | ||
| notting_ | and 1999 | |
| :) | ||
| nirik | in any case, what do we need fesco to do here? make sure the fix is pushed to all branches, etc? | |
| notting_ | so, it looks like the behavior in xscreensaver's defaults in F10 is to not use the net | |
| bpepple | ok, so we need to verify that this behavior is corrected in all our stable releases, and try to work with upstream on a solution. | |
| notting_ | but the problem comes with apps that wrap it? | |
| nirik | bpepple: there will be no upstream solution. | |
| bpepple | nirik: yeah, probably wishful thinking. | |
| halfline | where upstream == KDE upstream not xscreensaver upstream | |
| nirik | well, kde and gnome shouldn't be using all screensavers, they have a list I thought? | |
| halfline | i think if you use xscreensaver this isn't a problem | |
| this is only a problem if you use the xscreensaver screensavers from kde | ||
| pretty sure (although not 100%) | ||
| jds2001 | webcollage in any form was not turne don by default when i installed xscreensaver just now | |
| notting_ | rdieter: how does kde wrap xscreensaver stuff? | |
| jds2001 | this is on an F9 machine :) | |
| * stickster notes for bpepple, et al., that Docs will not meet today, and yields the balance of its time to FESCo | ||
| bpepple | stickster: cool, thanks. | |
| stickster | (and hopes you don't need it.) | |
| nirik | Kick__: did you enable that screensaver? what fedora version? what DE? | |
| bpepple | ok, so who wants to verify that this is working correctly (not showing questionable material) in our stable branches? | |
| Kick__ | bpepple: I'll check that | |
| bpepple | Kick_: great, thanks. | |
| anything else to add about this? Or should we move on? | ||
| --- bpepple has changed the topic to: FESCo-Meeting - Fedora representative to LSB? - https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00763.html - bpepple | ||
| bpepple | Ok, Russ offered an invitation to join in the LSB weekly call, and I didn't really see any follow-up on it on the mailing lists. | |
| * nirik has no objection to trying to find someone to do that, but does not step forward to be that person. ;) | ||
| bpepple | I sorta agree with him that someone from the new Server SIG would probably be a good candidate. | |
| nirik | perhaps we could put out a call for folks interested? or mail provenpackagers or something? | |
| or get someone from packaging? | ||
| bpepple | nirik: that's what I was wondering also. I think there's merit on having someone from Fedora being involved in the process. | |
| nirik | I think it might be good to at least have someone go and see whats going on and if having a seat at the table is worth it, or if it's a waste of time/effort. | |
| * jds2001 could do that, I guess | ||
| bpepple | nirik: agreed. I'll contact the server sig, and see if there interested. I just wanted to run it past the rest of FESCo before doing that. | |
| jds2001 | if no one else wants to :) | |
| jds2001 | bpepple: cool :) | |
| --- bpepple has changed the topic to: FESCo-Meeting - No meeting on 11/26? - all | ||
| dgilmore | +1 | |
| jds2001 | fine with me either way | |
| Kick__ | why ? | |
| notting_ | yeah, +0 from me | |
| bpepple | Ok, next week is a holiday here in the States, and I wasn't sure if we should have a meeting since a lot of folks will probably be traveling. | |
| * dgilmore notes that his baby is due in 2 weeks and could come any day now. when that happens ill not be around a week or two | ||
| Kick__ | ah | |
| dwmw2 | 0 | |
| nirik | also, if we don't slip, thats right after release. | |
| Kick__ | 0, no holiday here | |
| bpepple | so my question is who *won't* be available next week? | |
| * nirik will also be traveling, so +1 to skipping next week. | ||
| nirik also invites everyone to join in #fedora and watch the fun of release day/week. ;) | ||
| dgilmore | bpepple: my availabily is subject to change | |
| bpepple | ok, if nirik & possibly dgilmore are the only ones not available we should still have a majority of members here, so I say we plan on having it next week. | |
| everyone alright with that? | ||
| notting_ | sure | |
| Kick__ | ok | |
| j-rod | worksforme | |
| * nirik might be able to get on via EVDO, depends on coverage. | ||
| bpepple | ok, that's everything I had on the agenda. | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | anything else folks want to discuss, or should we call it quits for today? | |
| * bpepple notes we've already gone on for 2 hours. yikes. | ||
| * nirik is good to close up the meeting now. Tons of things piled up to do | ||
| Kick__ | ;-) | |
| bpepple | done. | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!