Extras/SteeringCommittee/Meeting-20070607

= 2007 June 7 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Jesse Keating	(f13)
 * Toshio Kuratomi	(abadger1999)
 * Bill Nottingham	(notting)
 * Kevin Fenzi 		(nirik)
 * Dennis Gilmore	(dgilmore)
 * Jeremy Katz		(jeremy)
 * Tom Callaway		(spot)
 * Rex Dieter  	(rdieter)
 * Christian Iseli	(c4chris)
 * Josh Boyer		(jwb)
 * Warren Togami	(warren)

OLPC

 * FESCo approved the proposal to allow OLPC to make use of our systems, and leaves it up to rel-eng and Infrastructure teams to make it happen reasonably, with weekly reports to FESCo. For a nice write-up of the benefits refer to: http://fedoraproject.org/wiki/OlpcFedoraPartnership
 * FESCo approved the proposal to make John Palmieri (J5) a sponsor.

Proposal for update tool defaults

 * FESCo approved the rel-eng proposal to have the update tool defaults pushing to updates-testing. For more details please refer to: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html

Security Updates needing Security Team approval proposal

 * FESCo is amenable to the idea, and is awaiting a proposal from the Security team.

Bugzilla component merge status

 * still being worked on. warren will poke some people to try to speed this up.

fedora-devel-announce list

 * FESCo approved warren's proposal for the fedora-devel-announce list. https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00377.html

Proposal Templates

 * FESCo gave general approval to f13's suggestion for a template for proposals that appear before FESCo, which will include items like 'when it will happen', 'who is driving it', 'whom it will effect', 'rollback plan', 'where in wiki will need to be updated'.

Misc

 * bpepple mentioned that he had briefly discussed with Max Spevack about possibly delaying the upcoming FESCo election a few weeks, so that the FESCo & the Fedora Project Board (FPB) could have the elections at the same time. This would also give time for the FPB to more clearly define the responsibilities of FESCo in the post-merge world.

Log
FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren I'm here. just sat down (: spot is here notting is here Hi everybody; who's around? Rathann sits in the back row c4chris here wwoods goes to back row, gets snacks f13 pings j5 ok, we've got a pretty full schedule today, so we better get started. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- OLPC - J5, f13 f13: you want to start this off> Hopefully j5 will show up in a moment. Ok, so, many of you saw the proposal I have, and j5 worked up a good wiki page. Let me find it real quick jeremy is here(-ish) s/$/e/ here http://fedoraproject.org/wiki/OlpcFedoraPartnership The basic idea is that to keep OLPC moving forward and basing on F7, we need to get them integrated into our infrastructure. this means basically branches in CVS, collections in Koji, packages on their own, packagers for said packages, and places to compose the collection So it's pretty much the same as EPEL. there is a lot of benifit to both sides in having OLPC play in our sand box, and can bring a lot of new life to Fedora in general, and new software interests. tibbs: there is a strong resemblance to EPEL with some small quirks Inherits from F7, overrides in some cases? yes and some packages just in OLPC not in any other FEdora collection Could you define "overrides" in that context? perhaps the hardest bit to swallow is that they will be bringing more packagers to the table. tibbs: some Fedora packages have to be "forked" for OLPC and modified in some ways  For instance gnome-vfs so it builds against the D-Bus version of GConf But that's not really different from EPEL. tibbs: so while dist-olpc will inherit from dist-fc7, lets say the kernel package is built specifically for OLPC and not inherited. f13: but those would be in their own OLPC branch, similar to epel tibbs: not really different no. spot: indeed. OK, so that's not the "overrides" I was concerned about. Goog. f13, does this mean more packages in the core OS will be split so deps don't pull in lots of irrelevant stuff for OLPC? (How disruptive can this become within F7's lifetime.) as long as the packagers go through the same sponsorship, cla, etc I don't really see a problem with it f13: Wait -- there are going to be packages in OLPC that are not in fedora-devel? warren: much of that work was done in OLPC FC6 days, with changes made to F7 during develoipment abadger1999: yes. f13, ah abadger1999: yes, there may in fact be OLPC specific packages. awesomely cool, did you want/need anything other than FESCo's blessing at this point? Will those packages need to go through a review process? yes they should adhere to the FEdora packaging guidelines and be reviewed and the packagers need to be sponsored what's the reason they won't go in Fedora? Another merge review! I'd like to make j5 a sponsor if possible, and spot who is also involved here is already a sponsor  c4chris: olpc-hardware-manage? manager that is J5: ah, ok  doesn't make sense in fedora right now that is Does it make sense to exclude/exclusive arch packages like that? J5 has a neat spreadsheet outlining what the package landscape looks like. ergh J5: I don't know; I could see having the package available. let people do what they want with it These package will get a devel branch so we'll have to make sure that those don't autobranch for F8.  there are also a lot of stuff that we want to get it but is not stable enough (we could put in devel) jwb: ? can infrastructure handle this? But really, this sounds like a fine idea. this is why i was wanting to make OLPC a secondary arch tibbs: we already have logic for that in our branching tools So this means that the XO software (not the final flash images, but the base packages) will be built in the Fedora build system? Because that's something people will think is totally cool. tibbs: we only branch things that were shipped in rawhide, so if it wasn't shipped in rawhide, no branch for it. wwoods: yes.  also GConf-dbus causes a lot of issues and isn't a drop in replacement yet because of hard linking issues wwoods: much of it is today on internal FEdora build system. Right, just thinkin' marketing and such wwoods: there is some that is done outside though, and it will be good for OLPC to bring it into a controlled environment, and good for Fedora as well f13, so would these have to go through review? jwb: yes.  the plan is to fully integrated by fc8 I think jwb: yes, anything new to hte party would have to go through review. My only concern now is the extra infrastructure load. ok... i think i'm ok with that at least, that's a constraint I'm putting on it from a FESCo POV J5: Do we eventually want GConf-dbus to be a dropin replacement, thoguh? tibbs: infrastructure load should be pretty light. J5: do you see an overall problem with making every "new" package to the Fedora world go through a review? (Is it part of the future for Fedora as well as OLPC)? tibbs, we'd been upgrading our load from DOOMED to DOOMED+0.01% heh  abadger1999: we want it to replace GConf upstream since ORBit is deprecated upstream but the codebase isn't ready yet. I'll be talking ot people at GUADEC about this we're not nearly as doomed as that (: tibbs: as far as build cycles? J5: I'd like to see the packages present in at least rawhide, then. jeremy: That and infrastructure team load as well. I.e people cycles. yeah, thats what I was meaning as well... I'd say we're at 850 millidooms abadger1999: but what if it's not viable by F8 though? tibbs: people cycles should be pretty minimal impact on the infrastructure side If they can be installed but not run.  f13: speed issues, we have until August to have a product out and the end of this month for the fc7 conversion but I don't think it will be too much of an issue anywho, that's a side subject. (Ie: I can install both gconf and gconf-dbus but only have gconf activate.) J5, what does OLPC gain by rebasing from FC6 to F7? concretely abadger1999: what might be nice for this is to have the concept of a rawhide-only package (i.e., never in the release) warren: python2.5 J5: ok. Dedicated work can get packages approved quickly though. notting: +1 notting: +1 notting: +10 J5, how many people, and from where, would the new packagers be? there goes the under 1000 review queue. ;) Oh well. warren: python 2.5, dropping many of the forks and being able to use the upstream packages  warren: we gain access to the fedora build systems for outside folk, python2.5 without forking 100 packages and a better community i want reviews, then i'm fine with it fine here too so, in the interest of getting this meeting done... Ok, are we at a point to vote on this then? and i want reviews with teeth Proposal:  Allow OLPC to make use of our system J5, as long as they follow the fedora rules I see no problem in this.  Sounds good. f13: +1 bpepple: I'm doing the proposal now. I just don't want the infrastructure team (volunteers) to be stuck.  It would be good will to have OLPC offer at least one volunteer to the team, and perhaps some bit of hardware as well.  warren: ya we wnt rules too keeps people honest f13: +1 f13: +1 Isn't spot's JOB to be part OLPC rel-eng? yep.  and I don't have to write them myself :) f13: +1 +1 spot should put some of his time in the fedora infrastructure, especially build +1 How much more of spot could we possibly get? Proposal: FESCo approves it in general, leaves it up to rel-eng and INfrastructure teams to make it happen reasonably, with weekly reports to FESCo. +1 +1 +1 +1 myself here. +1  as far as hardware, what do you need +1 +1 J5, i need an XO +1 +1  I think OLPC would love to have a mirror here i've got an XO, so we should be covered there spot, no, i need one that's a lot of 1's. jwb: hahaha, ok. f13: yeah, that's approved. f13: i voted several times. its a chicago tradition. J5: a mirror where? spot: LOL! what about having J5 being a sponsor?  at OLPC oh a Fedora mirror? +1 for J5 being a sponsor. I can mentor him as he gets used to our structure. n/m, lets talk about that elsewhere. bpepple, how about spot is the OLPC sponsor and J5 can be added after he gets me my XO? oh yeah. Proposal J5 as a sponsor (with spot as a mentor) +1 +1  hehe +1 +1 with the spot requirement +1 +1 with spot +1 +1 with spot we have to trust spot? +1 in spot we trust +1 I'd trust others as well but since he volunteered :-) ('cause he's my sponsor :-) ) great! damn. first, i don't get an award, and now i'm getting insulted in my own committee meeting? sure. looks like a green light for OLPC. We'll work with them on plans of attack and fill in FESCo as we go. Thanks! i bet i'm not getting that pony you guys promised either.  yay --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- rel-eng proposal for Update tool defaults pushing to updates-testing - https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html - f13 f13: another topic for you. it's a pretty simple proposal slightly OT: it would be awesome if there was an option for new packages to skip past updates-testing basically gives maintainers the ability to bypass testing, and gives QA/Rel-eng the ability to notice a bypass and scruitinize if necessary spot: see current proposal (: Update system defaults to updates-testing for new and update packages. If the package maintainer has a GOOD REASON they may skip testing, but they have to convince a rel-eng person that it is push-worthy, and they subject themselves to public shaming if they break something. spot: this gives any package the ability to skip past updates-testing at the maintainer's request  * rel-eng is proposing to FESCo that Update tool defaults to pushing to updates-testing  * Maintainer has option to "skip testing" and can do so without an "approver" roadblock.  * UPdate gets marked as "hot" somehow visually so that releng / qa can look over before pushing if necessary ok, so its on-topic then. I support this. +1 here also. definite +1 here. +1 +1 +1 here +1 +1 +1 I'm fine with letting maintainers request skipping testing, so long as there's a human gatekeeper warren: they don't necessarily have to "convince" rel-eng. rel-eng has the ability to stop /any/ update, skipped or not. +1 (lmacken and I agreed upon a cool color coded alert system for hotness too.) +1. is there a way for bodhi to easily push it back? f13, nod. +1 from me. i.e. maintainer requests and justifies, and rel-eng can (and should occasionally) say "no way, that's bogus, this needs testing first" notting: 'edit update, unpush' ? warren: the "you may not push the kernel directly to updates, period" button? could there be a way to mail on those or something? so we know who is doing them? wwoods: I think we can accomplish that by choosing to look at the hot potato updates if we wish. But I don't necessarily want to have to click into every hot potatio and click another button to make it go. notting, hotness is only a visual indicator, and not specific to kernel or anything. nirik: can you rephrase that? or clarify? notting, 0 days in testing RED, 1-3 days in testing ORANGE, 4-6 days YELLOW. Adjust as needed for political purposes. when someone skips updates could it mail the qa list or something? So we know what maintainers/packages are using that? that'd be a useful thing to know, yeah so we can say: hey, why are you not allowing testing? and spot trends, etc? you're going to get a lot of spam nirik: that's a possiblity. Hit up luke with a RFE I've also been toying with the idea of defining package tiers - tier1 packages would be stuff in the @base / @base-x group, tier2 stuff in the default install, etc. nirik, I think we can add the ability to subscribe to certain things. Maybe some other medium other than mail might be better though. so package tier might contribute to "hotness" wwoods, later man f13: ok. but yeah, that's.. a different discussion sorry, lots of stuff today wwoods, yeah, tier is a good idea too. ok, looks like this proposal passed, can we move on? move on f13: yes. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Security Updates needing Security Team approval proposal -- jbressers, jwb I would like the chance to know who is bypassing and have a chance to talk to them about using testing moving forward... but yeah. is jbressers around? jwb: I don't think so. not that i can see meant is he fetchable by doing a summoning dance or something heys' on PTO :/ ok but I can talk ab it about this, and so can lmacken if he's around jwb, could you please back up and explain why security team approval should be needed for security updates? warren, that's what i want jbressers for. it's really his request. i just said we should talk about it here internally we put in a roadblock to pushing security updates to let the security team review the text for accuracy. THere had been some mistakes in teh past and with security updates that's very very sensitive ah f13: does this include correct tagging of CVEs, etc? the security team is also doing the tracking of what is and isn't fixed in Fedora, so knowing when something is going out for security is very important to them. embargo compliance, details of update announcements being correct that could confuse and scare people notting: yes, making sure the right CVEs are referenced. warren: well, embargo compliance shouldn't be an issue on the *push* side who's on the security team? what we're asking for is to take this concept we had working internally and move it externally. jwb: there is a fedora security SIG IIRC, mark Cox, Josh Bressers, I think myself, but I'm not comfortable with reviwing CVEs for accuracy Ville and I are on it as well. can anyone in that SIG approve? lmacken is on it as well iirc http://fedoraproject.org/wiki/Security So here is the thing jwb: according to the wiki, bressers, dgilmore, f13, chris ricker, scop, tibbs, david eisenstien, lmacken I don't think the SIG has fully decided who all can approve, and what the criteria is. jwb: that would be the idea (or at least, that would be the idea if I'm going to endorse it ;-) however the security team would like pre-approval for drafting something like this up. we don't want to spend a bunch of time and energy on something FESCo is just going to say no to. f13: I think we agree in principle, but need to have a few of those specifics hammered out (I do at least :) makes sense to me. draft away but if FESCo is amenable to the idea, we can then spend the effort to come up with a nice proposal for FESCo to +1 jeremy: +1 jeremy: +1 +1 +1 +1 +1 for example, there need to be enough people so that waiting for security isn't a bottleneck to pushing out a needed security update, etc. +1 although I suppose I should abstain. (note, this is going to get some pretty nasty REGRESSION remarks IMHO) +1 -- make sure you have the rationale in the draft so the packagers knwo why it's a good idea. nirik: our security team never sleeps f13: I'm sure. ;) +1 f13: That kind of depends on the draft, I guess. nirik: I'm FAR more worried about there being people around who can sign the packages and do the push, rahter than a security person to approve it. f13: we get used to those now I guess :) f13: true. f13: I think you've gotten the buy-in from FESCo. +1, with pretty proposal ok, I'll let bress know when he gets back from PTO (and Mark Cox too) f13: thanks. --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- Bugzilla components merger status -- bpepple, poelcat warren: any input on this? poelcat ping? poelcat: asked me to bring this up. huh? do we have a status/eta on the bugzilla stuff. warren: he asked for it to be on teh schedule (: I've been getting status reports daily on the bugzilla merger there is nothing cogent on the wiki dkl assigned it to a trainee so progress has been slow i went to file a bug *cring* and found core and extras still there It *sounds* like they're close to doing it a wiki search turned up nothing helpful :) yeah, thisis really not looking good to the public yea, that starts to suck... I agree =( assigning something as important as this to a trainee? yikes. I'll jab dkl today in fact, right now he's not at his desk this delay is hurting us oh thanks ok, next topic? wwoods, want to jab him in person?   indicate that the delay is hurting us and the priority really must be stepped up. I'm satisfied. warren: thanks, moving on... --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- fedora-devel-announce list -- warren - https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00377.html warren: will do. Please treat this as a SEPARATE issue from the discussion lists as stated in mail thread, I'm +1 for this so long as the announcements still get to the existing fedora-maintainers or fedora-devel-list. This is merely an OPTIONAL thing that people can subscribe to and that it's moderated in this case: +1 and Reply-to: goes somewhere else f13, yes sure, mail on fedora-devel-announce goes to the discussion list. so why don't we use the fedora-maintainers-announce that was created long ago? fedora-devel-announce seems like a better name? I like it blue. (really, I don't care what we name it) yeah, will nuke it who are the moderators? nirik: I think that in the future, the plan is to nuke maintainers, so having fedora-maintainers-announce wouldn't make sense then. FESCo ? If it's optional, do the announcements also go to -devel or -maintainers? fine with me abadger1999, yes Okay. Then =1 please to one. +1 not both f13: yeah, I would like to see the mailing list reorg happen, but not gonna happen right away. and Reply-To: to fedora-devel-list +1 warren, +1 yeah, I'm happy with that. hurray for announcing to only one list and ending cross postings. +1 from me. +1 whatever warren says/wants. :) +1. do something,make sure it's *very clearly* announced and documented ooh... a planket vote. fesco folks are all moderators? or ? blanket spot: if you're already on fedora-devel, you wouldn't have to chagne filter. Messages would still get to you (: nirik, good question me is indifferent  i guess if somepeople want to half participate thats there choice Proposal FESCO gets to be moderators f13: or, not get to me, as the case may be. ;) Given the goal of this list is to use it INFREQUENTLY... jeremy, -maintainers isn't moderated jeremy: indeed seems that way but yeah, *sigh* jeremy, this is clearly different from the intent of -maintainers jeremy: hey, if we don't "solve" this problem every few years there can't be progress! we'll just solve it differently every couple of years (: OK I'll get the ball rolling to configure this. NEXT! warren: thanks. warren, woudln't it be better to coordinate it with the other stuff e.g. mailing list reorganisation? knurd, absolutely not. warren, one week waiting won't hurt that much knurd, mailing list reorg is controversial, this isn't. knurd: never ending doom. okay, me shuts up knurd, respectfully... warren, just detaikls This is really independent warren, what if we decide to drop the list prefix then people have to adjust their filers again wait another week and we might know if we drop the prefix in general knurd, the idea of an announce list is that you DON"T filter it. don't filter on prefix that's a horribly bad idea List-post: is a FAR better filter target Actually you should filter on List-ID: and that should never change even you rename the list. announce posts should be infrequent enough that people don't feel the need to filter. if they do filter, then we've failed in the intent of the list. OFFTOPIC or even List-ID agreed. filtering on prefix == U R DOIN IT WRONG moving on ... jwb: agreed. --- bpepple has changed the topic to: FESCO-meeting -- Statically link libuu (uulib-static) into klibido -- tibbs -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 don't make me fetch dwmw2 to give you all a lesson in mail filtering Well, I thought we could just deal with this on-list. But if folks want to deal with it here. tibbs|h tibbs I'm ok with onlist tibbs: I'm fine with doing it online. I like abadger1999's proposal next! --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Policy Drafts w/ wiki changes -- f13 back to you f13. ah! right so. I'd like there to be policy on implementing changes to policy/proceedure/whatever within Fedora uhh, you want us to have red tape on when we add our red tape? there should be a proposal template that covers things like 'when it will happen', 'who is driving it', 'whom it will effect', 'rollback plan', 'where in wiki will need to be udpated', etc... what kinds of things would this affect? that last one is a nightmare jwb: exactly, one we're very bad at. jwb: tell me about it, i'm still gutting "Extras" from things f13: +1 but i like the general idea f13: you volunteering to write this template? nirik: things like bodhi, security team, etc... spot: yes, I can start the template, and post to list to get suggestions/improvements in general sounds like a good idea. but I'd like FESCo's general approval to have such a thing and enforce it's use. sounds like a plan, we can review the template on the list. do it. from this meeting: olpc, security? spot: +1 nirik: yeah, those would be two good targets nirik: even the bypass updates-testing thing. and the announce mailing list. right the FPC has some really crude stuff, you could start with the GuidelinesTodo table so many of the things we decide in these meetings need to be properly documented somewhere and have fallback plans if things fail. It'll help us to make more informed decusions, and help hte policy maker realize what they need to change. sounds good to me shoudl those be filled out before we discuss them here? nirik: yes, and potentially adjusted from discussion here yeah, that would be great. f13: now you're regressing fesco! :) indeed I am. I was on change control boards in previous lifes and they do actually help, as much red tape as they can be seen as. f13: +1 We need something along those lines. There's a lot of leeway in how to do it so I imagine there will be a lot of feedback on the list. hopefully with good feedback you all can help me to make it as painless and helpful as possible. ok, I'm satisifed on this topic. f13: thanks. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora That went smoothly. wow, 10 mins to go and we went thru all the stuff... impressive secondary archs --> jcollie (n=jcollie@dsl-ppp239.isunet.net) has joined #fedora-meeting do we want them for F-8? maybe (: c4chris thinks yes dgilmore: I'd really like to see the infrastructure in place and an arch or two using it dgilmore: would sparc be ready in time? (at least thats the only arch that might be, right?) want, yes. Time to implement? That probably depends more on infrastructure than us. bpepple: put secondary arches on the agenda for next week, assign it to me. Is ppc remaining a primary arch? I received an e-mail from max asking if we might delay our election to coincide with the FAB election. we want them, we want them done right, lets not hold up a release to get them. spot: will do. warren: separate question bpepple: I'm in favor of that, fwiw warren: for today, yes. bpepple: I'm in favor of that as well. I'm not sure we can delay after we've already announced. bpepple: sure, why not... bpepple: One thing -- that would also require changes to the voting app. When is the FAB election? I guess if we could make it clear that the board is asking us to delay the election. bpepple: is it a good idea to turnover everyone at the same time? also, when is the FAB election? bpepple: at the request of the board we have rescheduled so both happen at once no big deal abadger1999: I'm not sure of the date. We've only talked about it briefly. tibbs: part of the reason is to address knurd's questions about split of responsibilities The thing is, we had an extablished election schedule. how long of a delay are we talking here ? tibbs, what's more important: follow the schedule or know what your are voting for jeremy: id like to aim for having sparc being done for F-8 even if we dont get a F-8 build out   but at least have things being built days, weeks, months ? c4chris: max mention a week or 2, but nothing definite. schedules can be adjusted if there is a need to; and I think there is a need to What does making the elections coincide gain us? dgilmore: sounds just peachy to me weeks is fine IMHO yeah, delay is on the order of a couple of weeks we've only had a very brief discussion so far. I just wanted to make sure FESCo folks were kept in the loop. jeremy, +1 f13, spot, jeremy, mbonnet_: can we get together sometime soon and work out how we should handle secondary archs in koji bpepple: tell max I said "no way in hell!" ;-) jeremy: will do. ;) dgilmore: 'badly'? :) dgilmore: sure! might be interesting to try and get the arm guys in on the discussion too dgilmore: sure, when? dgilmore: but let's discuss outside of the fesco meeting abadger1999: max and I will probably want to talk to you to make sure the election app can handle this. Okay.  We would also need to make the announcement of the delay to the lists. notting: should I say "We Will" bpepple: Okay. well, we can hold off the election according to our rules... we don't have enough nominations now I think. nirik: nomination period's not over yet, is it? trying to figure that. notting: not yet. anything else folks want to discuss? bpepple: is someone going to post guidelines as to what FESCO does and is responsible for? jeremy: don't we have to canvass for board nominations? nirik: question, are the "sponsored" seats in FESCo static?  IE do I have to run for re-election to keep my seat in FESCo? notting: eventually, yes it is still unclear to me who should run for a position on FESCO and if they were elected what their responsibilities would be f13: Did we decide to have sponsored seats? poelcat: that's one of the items that FAB and us are trying to finalize. max is working on a proposal. poelcat: that's part of the delay; max says he'll have something out today or tomorrow Rathann: We'll talk it over and vote next week. I'll make sure you get on the schedule. Rathann: we will talk about it this week I thought that we merged FESCo + Core Cabal but didn't make the seats sponsored. <Rathann> tibbs, dgilmore: thanks f13: currently, yes, I think you would have to run. f13: we decided that all 13 seats were up for election. bpepple, +1 Instead we were going to continue to delegate things to subcommittees. abadger1999: I'm really not sure (: I was on FESCO, I left it, then I got dragged back in, not sure if i wnat to say or go this time around. bpepple, that's how I remember it as well (Like the releng team) bpepple: cool. it might be good to mention that as a reason for delaying the elections :) f13: your call nirik: ok, I'll have to dig through email to find how how to re-up for election (: well, I think it's all up in the air some until we know about the FESCo/FAB responsabilities. would be good to have those spelled out. Is FAB or FPB meant? f13: regardless, I think we want someone representing rel-eng on FESCo. poelcat: when we decide on the final date for the election we'll explain the reasons why. wwoods warren rdieter: indeed. okay warren: I mix those up all the times. It should be FPB. i belive. rdieter: but I'm not sure if that 'representation' needs to be a voting member, just somebody who brings rel-eng topics to the table. f13: agreed. yeah, pesky tlas. ;( anywho, that would mean more restructuring of how FESCo is put together. I have another meeting to run to. cya! f13: later. Paid Time Off (i.e. vacation) c4chris: PTO == Paid Time Off. and TLAs - Three Letter Acronyms haha eh :-) anything else, or should we wrap up? f13: thx bpepple: wrap++ bpepple will end the meeting in 30 bpepple will end the meeting in 15 wwoods: thx too :) -- MARK -- Meeting End thanks, everyone!
 * tibbs here
 * warren here
 * nirik is here
 * abadger1999 her
 * jwb is hereish
 * nirik doesn't see any problem with this off hand.
 * bpepple agrees that this sounds like a good thing.
 * cweyl grabs a rabble seat in the back
 * jwb is appeased with the XO he'll never get
 * jwb jokes
 * jwb sighs
 * jeremy has known spot for far too long to trust him ;)
 * spot cries
 * jwb waits for wwoods to scream
 * nirik is on the list
 * warren confused why it was assigned to poelcat
 * dgilmore is here now
 * nirik doesn't care, just seems odd to have that list there never being used. Perhaps nuke it?
 * spot falls into the good idea, tell me the specifics when you're done so i can move my filter, crowd
 * jeremy just feels we had this discussion already and fedora-maintainers is what came out of that. *sigh*
 * knurd likes the idea, but would like to wait with the other stuff
 * knurd shuts up now :)
 * dgilmore is good with it
 * dgilmore thinks yes
 * Rathann would like to self-nominate himself to be a sponsor
 * rdieter nods
 * c4chris wonders what PTO and tlas mean...
 * bpepple will end the meeting in 60