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