| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| * dgilmore is here | ||
| notting is here | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| Hi everybody; who's around? | ||
| * tibbs here | ||
| spot is here | ||
| c4chris is here, hi All | ||
| nirik is here. | ||
| caillon is angry today | ||
| abadger1999 looks in | ||
| c4chris | c4chris: need a [] ? | |
| bpepple | ok, I see eight of us here, so we can probably get started. | |
| --- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-May/msg01414.html | ||
| bpepple | FPC had one proposal about withdrawing the JPackage naming exception. | |
| * jeremy | ||
| notting is +1. but i don't see anything in that report about the fpc vote | ||
| dgilmore | +1 | |
| nirik | is someone going to go thru and remove that and push new builds? at least for rawhide? | |
| * spot would like to note that the fpc vote was unanimous | ||
| nirik | +1 in any case... | |
| spot | nirik: i can do that. | |
| c4chris | +1 | |
| nirik | are we also going to change f7/f8/f9 ? or just rawhide? | |
| tibbs | notting: You're right; I seem to have forgotten to summarize the vote. | |
| jeremy | +1 | |
| spot | nirik: just rawhide | |
| bpepple | +1 | |
| spot | +1 from me | |
| tibbs | notting: The vote was unanimous among the seven members of the committee who were present. | |
| bpepple | ok, I see seven '+1', so FESCo doesn't object to the FPC proposal. | |
| * jwb is here now | ||
| bpepple | moving on, unless someone has something else to add to this. | |
| --- bpepple has changed the topic to: FESCO-Meeting - Cut-off date for new F7 packages - nirik, all | ||
| dgilmore | bpepple: we should be done | |
| nirik | I dont much care. For the last cycle we stopped at release time for the new one (1 month left in life) | |
| dgilmore | bpepple: i thought it was agreed that when when the second release is out there will be no more new packages | |
| dgilmore | nirik: :) i thought that was policy | |
| nirik | dgilmore: I thought so too, but I can't find anything codifying that policy | |
| and not sure why it was we did that... | ||
| bpepple | Is this a case we just need to put this in a policy then? | |
| caillon | i don't really think we should cut it off. if people want to support releases that we still officially support, more power to them. | |
| notting | well, considering it goes EOL a month after, stopping new packages now seems reasonable | |
| dgilmore | nirik: because at that point things should be slowing down | |
| bpepple | notting: +1 | |
| dgilmore | notting: thats why it was done that way in the past. the release should be preparing for EOL. | |
| spot | something related may be to consider having "release managers" for each release | |
| that person would be responsible for coordinating such efforts, may help distribute load better | ||
| * f13 | ||
| dgilmore | spot: sounds reasonable | |
| f13 | sorry I'm late, I had some people show up. | |
| bpepple | spot: yeah, sounds like a good idea to me. | |
| c4chris | spot: sounds good | |
| f13 | spot: I'm all for that | |
| nirik | sure, but if we are accepting new builds/updates, why not new packages? | |
| * f13 self nominates for rawhide. | ||
| nirik | in any case, I don't care much, just wanted to know for cvs processing. | |
| spot | f13: well, not rawhide per se, but F-10 | |
| which happens to live in rawhide now. :) | ||
| c4chris | any takers for F-7 ? | |
| * dwmw2 arrives | ||
| dgilmore | nirik: i think that at this point only serious bug fixes should be getting done for F-7 | |
| bpepple | dgilmore: +1 | |
| c4chris | dgilmore: I'd tend to agree | |
| dgilmore | nirik: if fixing a serious bug needs and update which needs a new package then so be it | |
| f13 | spot: yes but rawhide itself needs a constant release manager, which I would want to have responsibility of. | |
| drago01 | dgilmore: how do we define "serious bugs" or who is going to enforce that? | |
| nirik | dgilmore: sure... I would think exceptions would be made if need be. | |
| dgilmore | drago01: security/severe usability issue | |
| nirik | ok, so vote: disallow new f7 branches starting soon (say monday) and announce today? | |
| caillon | dgilmore, while i agree, we explicitly DONT have that requirement. | |
| bpepple | nirik: +1 | |
| dgilmore | drago01: by severe usability i mean it just doesnt work | |
| nirik: +1 | ||
| c4chris | nirik: +1 | |
| drago01 | dgilmore: ok | |
| caillon | dgilmore, we have had this argument many times on fedora-devel list where people want to rebase, change API, etc | |
| and others complain about it | ||
| and we just say "use best judgement" | ||
| dgilmore | caillon: :) yes | |
| caillon | so i don't see why F7 is any different | |
| dgilmore | caillon: the reason why we exteneded the release life was to allow people a month after a release to upgrade | |
| nirik | well, introducing new packages so close to end of life also leads to the possibility of a broken package going out, and then no time to update it... | |
| caillon | nirik, that can happen for anything that gets pushed in the next month, be it new or not. | |
| f13 | I'd prefer that we didn't do new packages, and left it up to maintainers best judgement with a heavy suggestion that only critical fixes go into F7 | |
| dgilmore | caillon: continuing to add new packages to F-7 does not give people incentive to upgrade to F-8 or F-9 until after F-7 is EOL | |
| in which time a security issue might crop up that we cant fix | ||
| nirik | caillon: true, but I think more likely for a new package that hasn't hit the entire F-7 userbase yet, over a package thats been in and working. | |
| spot | perhaps we should cut off new F-(X-2) packages when F-X goes gold? | |
| notting | spot: sounds good to me | |
| jeremy | spot: +1 | |
| tibbs | Could we perhaps ban them by default but allow them with justification? | |
| nirik | spot: yeah, that is what we did last time... just not codified. I would be ok with that as a policy moving forward. | |
| dgilmore | spot: thats what i thought we decided upon last release | |
| tibbs | Many people just request them because they know F7 is still supported. | |
| bpepple | spot: +1 | |
| dgilmore | spot: its what we did. I guess we didnt chisel it in stone | |
| f13 | haha, we probably did decide that and nobody codified it | |
| c4chris | spot: +1 | |
| caillon | dgilmore, i don't think people need incentive to upgrade. they either will or they won't. there are still people on RHL 7.2 | |
| * f13 is welcome to suggestions for wording in the ReleaseEngineering/Overview page | ||
| bpepple | so, where on the wiki do we need to put this? | |
| dgilmore | caillon: my last job i had a RHL-6.1 box | |
| spot | probably on the cvs request wiki page | |
| caillon | exactly :) | |
| * nirik notes we should add that item to the release checklist... "mark no new branches in F(X-2) and update cvsadmin page" | ||
| caillon | dgilmore, and walters has a patch to nag people to upgrade when there's a new release out. | |
| bpepple | spot: do you want to add it, or you want me to? | |
| spot | bpepple: please, add it. i've got more than enough on my plate atm. | |
| bpepple | spot: works for me. | |
| caillon | (for the record, -1 from me for this proposal) | |
| f13 | please also add it to the ReleaseEngineering/Overview page | |
| bpepple | f13: will do. | |
| f13 | I want to keep that a good source of info as to how we do releases. | |
| bpepple | ok, anything else on this or should we move on? | |
| dgilmore | lets move on | |
| --- bpepple has changed the topic to: FESCO-Meeting - Kernel-libre: http://fedoraproject.org/wiki/Features/FedoraFreedom - all | ||
| f13 | currently pending requests will be honored? | |
| dgilmore | f13: yes | |
| dwmw2: please speak up here | ||
| dwmw2 | pfff | |
| bpepple | Is Alexandre around? | |
| jeremy | lxo ? | |
| f13 | spot: can you wait on touching jpp packages in rawhide until I've got something from the jpackage folks? I'll get something before Alpha. | |
| dwmw2 | I set out what I believe to be the best way to approach this | |
| lxo | I am | |
| spot | f13: ok. | |
| dwmw2 | kernel-libre is not it | |
| f13 | dwmw2: +1 | |
| spot | good intentions of kernel-libre aside, i agree with dwmw2, a forked kernel is not a viable approach. | |
| c4chris | same here | |
| lxo | please drop the forked | |
| there's no 'fork' in that | ||
| notting | so, two points: 1) we don't allow alternative kernels - ergo, kernel-libre as it is described does not fit 2) we don't allow random conflicts without specific reason. ergo, fedora-freedom does not agree with the guidelines | |
| dwmw2 | lxo: that's only true if you feed your patches upstream. Which is what we're asking you to do | |
| lxo | can you please explain why you think that's not viable? | |
| I don't have patches | ||
| spot | lxo: you're scraping out the parts you dont like and making a new tarball. | |
| thats a fork. | ||
| dwmw2 | lxo: that was question and answer, wasn't it? | |
| notting | given that both #1 and #2 don't go with the guidelines, having a spin including them can't be called Fedora. so, -1 overall to the feature | |
| lxo | so, Fedora doesn't want a Freedom feature | |
| dwmw2 | lxo: seriously, let's get the upstream kernel to the point where we can strip out the blobs | |
| lxo: yes, we do. But we want it done right | ||
| lxo | see above | |
| * spot agrees with dwmw2 | ||
| lxo | no conflicts with non-Free firmware | |
| f13 | and now we're going in circles again | |
| lxo | therefore, no assurance to users that they can use Fedora in Freedom | |
| dgilmore | lxo: we want the work to happen upstream so that it benefits all users not just ours | |
| lxo | can we please disregard the linux-libre approach for a moment and consider where we want to get? | |
| what's our mission? is freedom a feature indeed? how do we want to offer it to our users? | ||
| f13 | lxo: we'd like to get to where all firmware are in their own packages so that one /could/ make a subset of Fedora packages into a "free²" spin. | |
| spot | lxo: i don't think anyone disagrees on the idea of separating the firmware inside the kernel, but it needs to be done cleanly, in upstream. | |
| tibbs | Your devinition of freedom is not the only definition of freedom. | |
| lxo | I get the impression you're getting distracted in opposing one particular approach you dislike, and throwing the baby along with the bath water | |
| dwmw2 | lxo: it would be great to get to a point where we can ship a spin without the binary firmware | |
| tibbs | I would be much less annoyed by this discussion if it didn't have so much loaded language. | |
| lxo | so what's fedora's definition of freedom? | |
| dwmw2 | I'd like the 'normal' kernel to support that, but allow users the freedom to add bits of firmware which they need | |
| lxo | dwmw2, I don't see that happening in upstream kernel any time soon | |
| honestly | ||
| it *is* hopeless | ||
| dwmw2 | lxo: I don't agree. | |
| spot | lxo: if someone who is motivated to take on that work actually starts doing it, it will happen. | |
| dwmw2 | it's hopeless if you refuse to even try, and a priori refuse to send patches :) | |
| cebbert | you want to ship a spin without firmware updates for processors so people can experience CPU bugs? | |
| lxo | people have started that before | |
| dwmw2 | if it's important enough to someone to actually get on with it, it'll happen | |
| lxo | it was actively pushed away | |
| f13 | lxo: it was broached... poorly | |
| notting | lxo: fedora *works with upstream* | |
| spot | lxo: there is a noted difference between "YOUR KERNEL IS UNCLEAN, FIX IT NOW" and "here's a patch to separate the firmware from the driver" | |
| dwmw2 | lxo: I have outlined an approach which I think would have better success | |
| lxo | it's pointless to repeat what hasn't worked before | |
| dwmw2 | if done sensibly | |
| f13 | lxo: do it within reason and you've got something. Do it as a fanatic and well you get plonked. | |
| dwmw2 | i.e. not refusing to send patches. | |
| notting | lxo: then why are we having this conversation again. it certainly hasn't worked before. | |
| f13 | lxo: Can't never could because he never tried. | |
| lxo | notting, what does fedora do when upstream has implemented policies that conflict with our goals? | |
| dwmw2 | lxo: 'pointless to repeat what hasn't worked before' has _always_ been untrue in Linux development | |
| notting | lxo: do not conflate yours with mine with the project's | |
| dwmw2 | and I've recommended that you do not merely repeat; I have made a different suggestion | |
| lxo | I'm talking about Fedora's stated mission of building an operating system out of free and open source software | |
| f13 | a "working" operating system perhaps | |
| but again, now we're down to arguing about words instead of talking about the actual issue. | ||
| dwmw2 | I propose that FESCo's response be "We'd love this feature, but it needs to go upstream first and not involve an alternative kernel package." | |
| spot | dwmw2: +1 | |
| lxo | dwmw2, I'll have to get back to you to even begin to understand what you're suggesting. it appears to me that the suggested use case is already covered | |
| f13 | lxo: we'd like to see you succeed in your mission. We've given you examples of how to do it that would be acceptable to Fedora. Either do it or don't. | |
| caillon | lxo, we also have another feature which is "we work with upstream". and given how not working with upstream hurt debian's openssl package, i'd like to not give up that feature for your feature on such critical packages. | |
| c4chris | lxo: that's what we do, to the best of our belief. It migth be our belief does not exactly coincide with yours, but that's life | |
| bpepple | dwmw2: +1 | |
| nirik | dwmw2: +1 | |
| jeremy | dwmw2: +100 | |
| lxo | caillon, again, what happens when upstream has goals that conflict with ours? | |
| do we blindly follow upstream just because it's upstream? | ||
| notting | lxo: i'm not here to argue semantics. fedora has, *as a project*, approved the use of firmware that may not fit your definition of free. your semantical arguments about mission are, in essence, saying we should reconsider that decision. that is *NOT* the reason we're having a discussion now, so that's pointless to be discussing now | |
| dwmw2 | lxo: to start with, augment the kernel's own firmware-loading class so that as well as loading firmware from userspace, it can also load one of a set of firmwares which were built in to the kernel image. | |
| notting | dwmw2: +1 | |
| f13 | lxo: what we do when that happens is we work with upstream to get to a point where we're in harmony. | |
| notting | (to 'upstream first') | |
| dwmw2 | lxo: then, convert all users of firmware blobs to the firmware class, completely isolated from complaints of regressions because people have to use initrd,, etc. | |
| c4chris | dwmw2: +1 | |
| notting | f13: and then a coca-cola commercial! | |
| dwmw2 | then, we can move the blobs to a separate tarball or something. People still have the _option_ of building them into their kernel | |
| spot | notting: with polar bears? | |
| dwmw2 | but Fedora, which uses an initrd everywhere, would not need to | |
| caillon | lxo, then we change upstream's goals. it wouldn't be the first time we need to convince upstream. but we do it using sane arguments, not just complain. | |
| notting | spot: in tunisia | |
| dwmw2 | problem solves, and people can still boot monolithic kernels on their machines which need SCSI controller firmware | |
| cebbert | obviously the commercial should have penguins | |
| jeremy | lxo: and rather than a package full of conflicts, you could easily write a yum plugin which checked the license of packages being installed and give a loud warning if suitable | |
| lxo | do you honestly foresee a say linux-2.6.39.tar.bz2 without any such non-Free firmware if someone follows your suggested plan? | |
| f13 | lxo: yes. | |
| lxo | I seriously don't. people will complain because they now have to go fetch the firmware from some other tarball | |
| jeremy, this is not about the license | ||
| f13 | lxo: then you might as well pack up and go home. | |
| notting | jeremy: lxo: well, if you're doing a spin, just Don't Include those packages. don't worry about conflicts/plugins | |
| caillon | lxo, we do have a lot of sway with upstream kernel given how much we contribute to it. and i really think we can get a patch upstream if done right. if you don't want to do it right, that's your prerogative. we don't want to take it if it's not done right. | |
| lxo | please don't conflate license with having your freedoms respected. these are related, but quite distinct issues | |
| dwmw2 | lxo: if we get to stage 2 of my 3 stages, and it's just the tarball, then I would support Fedora splitting that out. | |
| cebbert | who get to handle all the bug reports against the kernel after the package gets split out? | |
| dwmw2 | cebbert: pjones. It's a mkinitrd thing | |
| lxo | dwmw2, but that's what I do now! why should I put in weeks of work and discussion and tolerance to verbal abuse just to get back where I am now? | |
| jeremy | notting: the conflicts or plugin would then let you add more software later and not worry about getting things that don't meet your criteria | |
| cebbert | I'm sure he'd just love htat | |
| dwmw2 | lxo: no, you do something different now. | |
| f13 | lxo: you don't split it out in a way that is sane and easy for those that wish to opt back into the firmware | |
| lxo: and you don't do it in the existing kernel package. | ||
| dwmw2 | the difference is that people would be able to just drop in the appropriate blobs if they need them (and Fedora would ship them in the default spins) | |
| f13 | we're not going down the route of having two kernel srpms again. That was a huge mistake, we wont' do it again. | |
| lxo | notting, this is not just about spins. this is about user choosing "I don't want non-Free stuff from Fedora installed on my machine". | |
| lxo | "if any updates attempt to bring it in, stop right there" | |
| dwmw2 | cebbert: they'd be in the default install; the only time it would matter is when it's needed for the boot device. So we'd need firmware loading in initrd -- but don't we have that already? | |
| notting | wow, it's the GPL-is-infectious argument in reverse | |
| lxo | GPL? who's talking about GPL? | |
| cebbert | lxo, and if your system crashes because you don't have the latest Intel CPU firmware you get to replace the processor | |
| dgilmore | dwmw2: we have it. i have a box that has fiber channel storage as the primary storage. upstream kernel removed its firmware and now it gets loaded by initrd | |
| * spot wonders if this is productive. | ||
| dwmw2 | dgilmore: right. | |
| notting | lxo: you're using the standard corporate 'if any GPL software touches me, I'm infected' in reverse against non-free software | |
| dwmw2 | and that's the way forward | |
| lxo | cebbert, so do *you* get to decide the user must not be able to choose that? | |
| cebbert | dwmw2, we're still going to get bug reports from people who don't have the latest firmware and think the kernel is at fault | |
| dwmw2 | cebbert: the in-kernel firmware almost never changes, I thought? | |
| cebbert | lxo, I just don't want a pile of bug reports from people who choose to go that route | |
| lxo | dwmw2, that's mostly correct | |
| dwmw2 | and we can put Conflicts: into the kernel package to make it dislike earlier firmwares | |
| spot | Proposal on the floor is "We'd love this feature, but it needs to go upstream first and not involve an alternative kernel package." ... do we have enough votes for it to pass? | |
| notting | spot: yes, seven | |
| lxo | bnx2x firmware and nouveau voodoos are changing quite constantly | |
| f13 | spot: +1 | |
| nirik | +1 on the proposal on the floor | |
| dwmw2 | jeremy gave it 100. Isn't that enough? | |
| tibbs | spot: +1 | |
| spot | +1 | |
| bpepple | +1 | |
| c4chris | +1 | |
| lxo | (and there's no copyright notice covering the voodoos, or permission to distribute them, BTW; something to look into) | |
| dwmw2 | +1 | |
| * jeremy reiterates his +100 | ||
| dwmw2 | lxo: they're a clear GPL violation as far as I can tell. But that's a different issue :) | |
| dgilmore | +1 | |
| lxo | so, no FedoraFreedom, is that what you're deciding? | |
| dwmw2 | lxo: no. It's not. | |
| f13 | lxo: stop being a drama queen. | |
| lxo | or are you just ganging up against one particular implementation detail? | |
| bpepple | ok, so I count nine "+1", to spot's proposal. | |
| abadger1999 | lxo: " it needs to go upstream first" | |
| f13 | lxo: we're deciding that we want our Freedom done right. | |
| spot | lxo: its not the spirit, its the implementation. | |
| dwmw2 | lxo: we're saying _yes_, we want this feature. But done right. | |
| nirik | lxo: no, we are saying we would love to have it... go do it the right way. | |
| lxo | ah, sorry, I had missed spot's proposal | |
| I apologize | ||
| too many things going on at once | ||
| mea culpa | ||
| bpepple | lxo: no worries. | |
| caillon | spot, +1 to that proposal | |
| lxo | so... designing a backup plan | |
| dwmw2 | lxo: is there anything unclear about the plan I outlined? | |
| lxo | what if upstream refuses to take changes as proposed by dwmw2? | |
| spot | lxo: we can revisit it if/when that occurs. | |
| dwmw2 | we promote an attitude of violence towards them | |
| caillon | lxo, let's cross that bridge if it occurs | |
| dgilmore | dwmw2: we never do that. | |
| lxo | so, backup plan is wait and see | |
| nirik | lxo: you might pass your changes by dwmw2/alanr/other fedora kernel folks before posting upstream? | |
| c4chris | -ENOCRYSTALBALL | |
| lxo | you know... we could have a backup plan right now | |
| notting | nirik: alanc? | |
| nirik | notting: right, sorry... | |
| lxo | say, if upstream kernel doesn't take it, we go ahead with the changes anyhow | |
| notting | lxo: you have the persistence of a 5-year old who wants to go to the swimming pool | |
| * nirik points to the cart, and the horse, and the order they are in. | ||
| caillon | lxo, i believe it's a good feature. you believe it's a good feature. i think we all agree it's a good feature. i believe upstream will agree too (though i can't speak for them). so i see no reason to expect upstream to not take the feature based on the feature itself. | |
| lxo, thus, the only reason i can see them rejecting it for is implementation. | ||
| dwmw2 | lxo: I can't see _any_ problem with parts 1 and 2 of my plan. And as I said, I'd support Fedora doing part 3 on its own | |
| f13 | and I see no reason to get worked up and spend offert on a fictional backup plan. | |
| lxo | caillon, that's where we differ. I find it extremely unlikely that upstream will go for it. and I have the scars to explain why :-) | |
| f13 | it's not worth FESCos time. We've decided, MOVE ON> | |
| dwmw2 | caillon: that or the possibility that people refuse to post patches in 'diff -up' form :) | |
| notting | dwmw2: of course you can't see any problems, you proposed it ;) | |
| spot | bpepple: i think there is not much left of this horse. | |
| lxo | it's not just a matter of rejecting the implementation | |
| dwmw2 | notting: dude, I propose kernel code all the time that I see problems with :) | |
| f13 | lxo: perhaps it wasn't the idea that upstream shot down, but the way in which it was presented. | |
| lxo | it's a matter of sacrificing a bit of convenience out of respect for users' freedom | |
| bpepple | spot: I agree. we should probably move on..... | |
| caillon | dwmw2, heh | |
| lxo | that's just not something in LKML's radar | |
| dwmw2 | lxo: when you post the first patch of the 3, I don't want to see _any_ mention of freedom in it | |
| f13 | bpepple: what's our next topic? | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| dwmw2 | that goes for the second patch, too. | |
| that'll help | ||
| lxo | I'm not going to post it | |
| I'm going to send the ed diff to you | ||
| bpepple | f13: there's nothing else on the agenda for today. | |
| lxo | as you proposed | |
| dwmw2 | heh, ok :) | |
| notting | well, the ed diff requires #1 and #2 to be there first. so is *anyone* actually going to do that work? | |
| bpepple | anything else folks want to discuss before wrapping up the meeting? | |
| lxo | and I'll do that if I manage to convince myself that this will indeed advance the cause of freedom, and that this is more important to do than my other activities in this regard | |
| jeremy | anyone with comments on the feature process and improvements for f10 should send them to poelcat | |
| cebbert | could we get a "freddom" spin to pass some parameter to the kernel that indicates it's opted out of firmware loading? | |
| lxo | notting, what does 'being there' have to do with anything? I do have these files, of course. I clean them up, after all. | |
| poelcat | jeremy: or better add them to the wiki page | |
| notting | lxo: #3 is not acceptable as is without the framework of #1 and #2 to make it *usable* | |
| lxo | I object to promoting the use of the stuff that's in there, to distributing it. | |
| jeremy | poelcat: indeed! | |
| * poelcat is lurking in airport mode | ||
| notting | poelcat: jeremy: along those lines | |
| bpepple | ok, I don't see anyone speaking up, so I think we can wrap it up for this week. | |
| * bpepple will end the meeting in 60 | ||
| notting | i wonder if rather than handling F10 stuff in FESCo, board, releng multiple times a week, if there should be a standing Fedora 10 meeting | |
| with some subset of all those groups | ||
| and perhaps feature approval goes there | ||
| poelcat | notting: like a "project meeting" ? | |
| lxo | cebbert, freedom spin built out of sources that contain non-Free doesn't make much sense to me. it fails the goal | |
| jeremy | notting: definitely worth at the very least thinking about | |
| notting | poelcat: something like that | |
| maybe i should send something to the list | ||
| bpepple | notting: might be worthwhile. since we don't tend to get to anything else when feature time comes around. | |
| dgilmore | notting: with someone responsible for the whole release. that will see it through to EOL | |
| poelcat | notting: i'd be willing to consider leading it if that would help.. maybe along the lines of our release readiness meetings | |
| notting | at a minimum you'd want representation from rel-eng, board, fesco, all spin-producing SIGs/teams, QA, docs... | |
| poelcat | could even meet less than every week if there are not a lot of topics | |
| notting | but i suppose there would be overlap (who approves schedules, who approves features, what does fesco do then, etc.) | |
| * nirik suspects if you get too many people it's going to take even longer than when fesco was discussing them. | ||
| bpepple | truthfully, I'd like to restart the discussion on the responsibilities for FESCo again now that F9 is out the door. | |
| poelcat | we've found that to wokrk well internally | |
| nirik: right.. the rr meetings were one rep from each group | ||
| nirik | bpepple: agreed. I think we should look at doing more proactive things rather than just sitting around. | |
| jeremy | bpepple: it's probably worthwhile ot try to figure that out before we elect ourselves... | |
| warren | jeremy: +1 | |
| bpepple | jeremy: agreed. | |
| maybe at next week's meeting we could work on that. | ||
| c4chris | k | |
| nirik | bpepple: sounds like a good plan to me. | |
| tibbs | The problem with being proactive is that you need the ability to direct others to do things. | |
| poelcat | nirik: and we did them on the phone which made them much more efficient | |
| tibbs | In a volunteer project it's tough to do anything other than ask people to do things. | |
| * poelcat has to run | ||
| notting | ok, so table the 'Fedora 10 group meeting' plan until after next week when we discuss a better idea of what fesco is doing | |
| bpepple | notting: sounds like a plan to me. | |
| notting | (this idea came out of the multiple-postpartum-meetings for fedora 9) | |
| f13 | I do really like the idea of an Asterisk based "F10" meeting every couple weeks or every week. | |
| that could conveniently coincide with release readyness meetings | ||
| notting | f13: is asterisk ready yet? | |
| f13 | (IE be one in the same) | |
| notting: I think it's usable for smaller sets of folks who can get their equipment in working order | ||
| bpepple | f13: I'm not really a fan of conference call meetings, since there is no record for the rest of the project (which is my #1 beef with the Board). | |
| f13 | especially if we ask infrastricture nicely to make that happen for us | |
| nirik | tibbs: agreed... but one resource we have is the fesco members. We can tell ourselves what to do... ie, mentor features, etc. | |
| * nirik also hates phones. ;) | ||
| f13 | bpepple: yeah, that does suck, but voice is just such a higher bandwidth :/ | |
| f13 | notting: failing asterisk, we can do things with global meet | |
| nirik | fudcon might also be a good time to have a 'what should fesco do' session. | |
| notting | nirik: is that post-election? | |
| bpepple | nirik: unfortunately, it's after the election/ | |
| tibbs | nirik: To some degree, but I don't think the committee is useful if the committee members have to do all the work themselves. | |
| f13 | bpepple: anything done on the phone absolutely needs to have a notes / minutes taker | |
| tibbs | Anyway, time to run. | |
| nirik | yeah, true... bad for election timing. ;( | |
| * warren looks at the nomination page | ||
| bpepple | f13: yeah, but there's always parts of the conversation that is lost in translation. | |
| warren | perhaps the election for fesco makes a lot more sense after we DEFINE it | |
| meaning, we should delay the election | ||
| notting | unless we can define it beforehand :) | |
| dgilmore | bpepple: we are working on making sure conference calls are recorded on our asterisk setup | |
| warren | http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations we don't have enough people to even hold an election on this page | |
| cebbert | lxo: all I want is a flag passed to the kernel that tells me I can ignore a bug report because there's no firmware available | |
| bpepple | dgilmore: that would be good. | |
| warren | we have 2 people running plus one contingent | |
| bpepple | warren: I expect most people will sign-up about a week before the election, just like has happened in the past. | |
| nirik | dgilmore: good, but still not as nice as a transcript... perhaps we could get some folks willing to listen and transcribe... | |
| warren | (Foo Bar isn't eligible due to the felony convictions.) | |
| bpepple | warren: ;) | |
| * nirik still hasn't decided if he will run again or not... | ||
| notting | cebbert: heh | |
| bpepple | nirik: I haven't either. Figure I'll make the decision next week. | |
| nirik | yeah, me too... | |
| warren | perhaps this is an important sign? | |
| dgilmore | nirik: we are also working on making sure that it can be streamed live | |
| warren | that we need to define fesco before electing it | |
| nirik | dgilmore: cool. | |
| warren | people don't know if they want to run if it isn't defined | |
| nirik | dgilmore: I should try again to get my bluetooth headset working. | |
| warren: yeah, agreed... | ||
| dgilmore | nirik: i keep meaning to buy a bluetooth headset | |
| bpepple | warren: hopefully at next week's meeting we'll be able to do that. | |
| warren | so we either define fesco before the deadline or we delay the election | |
| nirik | dgilmore: I have a pile of them... can bring you one at fudcon if you want. :) | |
| dgilmore | nirik: :) would be cool | |
| bpepple | ok, we're at the hour, so I should probably call time of death. | |
| * 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 | |
| Thanks, everyone! | ||
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!