Extras/SteeringCommittee/Meeting-20070215

2007 February 15 FESCo Meeting

Members

Present

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

Absent

• Andreas Bierfert (awjb)
• Josh Boyer (jwb)

Summary

Core/Extras Merge

• FESCo ratified the CVS administration with flags proposal.
• warren is going to continue working on the core package review procedures, and the plan is for FESCo to vote on it at the 2007-02-22 meeting.
• notting brought up a proposed change to owners.list, which would list multiple owners in the owners section. FESCo approved this change.

Sponsor Nominations

• rvolkal was nominated and accepted.

Packaging Committee Report

• FESCo didn't have any objections to the Packaging Committee's guidelines regarding:
• Jpackage naming policy
• spec file naming clarification

Log

<bpepple> FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
<tibbs> urp
<c4chris> here
<bpepple> Hi everybody; who's around?
* spot is here
<warren> hi
* rdieter here
abadger1999 is here
nirik is here.
<bpepple> Ok, looks like we have enough folks around to start.
--- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process
* Bob-Laptop sits in the cheap seats
thl is on the rabble seats for 20 - 30 minutes
<bpepple> warren: is the core review process still being discussed?  I haven't seen any discussion on it in a few days?
* dgilmore is here
<warren> bpepple, last week we discussed a desire for FESCO to make a decision about how the review process should be finalized.
<warren> too much disagreement on the list
My feeling is that only a vocal minority has been against one aspect
<bpepple> Is that bug assignment side of it?
<warren> yes
<abadger1999> I'm a non-vocal somehwhat against it.
<warren> and perhaps the bugzilla tool is just too unwieldy to do that
<bpepple> Personally, I don't have any problem with assigning the bug to who's step it is.
<warren> I'm exploring an entirely different option with flag assigned-to (currently not enabled) before throwing in the towel.
<nirik> warren: was anything decided about switching - and ? during review? If thats dropped and left for ? for "under review" and - for "rejected, problem with license, etc" , then I am happy.
<warren> bpepple, yes, it works, only the interface makes it error prone.
<warren> nirik, that part has change d
<nirik> warren: ok.
<warren> Could we focus on ratifying the CVS procedure first?
that is less contentious
<f13> sorry, a bit late.  but I'm here.
<warren> I'm leaning toward notting's desire to use fedora-cvs+ even though it isn't too useful.
<bpepple> warren: that's fine with me.
<warren> fedora-cvs+ at least sends an explicit mail saying it is done.
* rdieter is ok with whatever warren comes up with. (:
<abadger1999> CVS Procedure seemed like a definite improvement.
* c4chris already +1'd the CVS stuff on the list.  Don't care either way on th e+ flag.
<warren> OK, the fedora-cvs- and fedora-cvs+ part will change a bit from the current draft, but vote to ratify?
<bpepple> +1 on cvs+.
<warren> I just want to go ahead and update the documentation regarding this.
<nirik> +1 here
<c4chris> +1
<dgilmore> id rather the +
<abadger1999> +1
<notting> +1 to +. mm, punctuation.
<tibbs> I was +1 on the list for CVS stuff, still +1 now.
<warren> OK, just doing it
OK... so back to reviews...
<f13> +1
<nirik> warren: you are going to also update the wiki? that needs doing pretty badly given the confusion..
<bpepple> nirik: agreed.
<warren> What are your opinions regarding assignment to next actor?  Is it good enough to do, ignoring for now the user interface issue because that can be worked around in the meantime with training?
nirik, yes
* bpepple is fine with assigning to next actor.
<f13> perhaps cvs-import should be modified as well to just full stop if the directory you're trying to import to doesn't exist, to prevent half imports
<warren> Anybody want to take f13's suggestions?
<nirik> I personally am fine with it, but I think it's a bad idea in general, as submitters aren't going to know the process, so aren't going to ever do it... or seldom will at least.
<warren> Oh, one more thing on the CVS topic.
We need a Europe timezone CVS admin
<nirik> I think moving the burden on the reviewer to add NEEDINFO is better, since they will be expected to know the process.
<bpepple> f13: we could talk about that when we discuss the cvs-import later in the meeting.
<c4chris> I don't think re-assigning all the time is necessary.
<warren> I was half won over by Mamoru's reasoning in one of the posts...
<notting> f13: that should be easy.
<abadger1999> warren: Do you have a link to the latest draft?  My INBOX overfloweth.
<warren> That the reviewer must be kept assigned on the bug, because the reviewer is enforcer.
<f13> I'm in favor of NEEDINFO not reassignment.
<warren> argh
<c4chris> Having ticket reporter be the owner and siigned-to be the reviewer made things pretty simple when looking at a package history
<dgilmore> f13: me too
<warren> I'm just going to recompile all this into another draft.
move on for now
* rdieter thinks if as much energy talking *about* reviews was put into *doing* reviews, we'd all be better off. (:
<bpepple> rdieter: +1
<abadger1999> rdieter: :-)
<tibbs> I have to agree.
<jima> *sigh* true.
<bpepple> warren: ok. moving on.....
<tibbs> I'm sort of stuck right now with open review tickets; I'm not sure what the process is supposed to be so they don't move forward.
<f13> rdieter: herding cats takes effort :/
--- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- status update
<rdieter> new rule: for every complaint about new review process, must do 1 review.
<nirik> it would be very good to get this set soon... if there is another draft, could we perhaps review and approve it via mailing list instead of waiting until next week?
<bpepple> nirik: that's a good idea.  anyone have a problem with that?
<rdieter> nope, sounds good.
<jima> rdieter: +1 (rabble)
<c4chris> warren, I can prolly help for CVS if needed.  I live in Switzerland...
<bpepple> warren: when your done with your draft, could you send a message to the mailing list?
<bpepple> Are there any other items we need to discuss in regard to the Core/Extras merge?
<c4chris> any info on sponsoring RH people?
<f13> I sponsored a handfull of them.
<nirik> whats the status on the package db/ updates system/ build system?
<f13> c4chris: we're trying ot get some key folks in various offices to be sponsors, so that they can in turn sponsor the rest of their peers
<dgilmore> nirik: we have buildsystem code we need to plan the code updates and test it
<warren> bpepple, I always do
<bpepple> warren: thanks.
<c4chris> f13, cool.  Just yell if you need help there
<thl> f13, it it really wise if rh guys sponsor all the other rh guys? some people will complain
<f13> nirik: a koji project was started, some code donated, with features we want for th emerged world.  Work is ongoing to get a test system up and running.
thl: how is it not peer sponsorship?
<notting> nirik: packagedb is not a gating feature. updates system can be worked in parallel. build system is ongoing.
<f13> thl: We're putting our name on the line for other RH folks.
it makes more sense as we can have meetings and training sessions for these employees in our offices
<thl> some people might complain that red hat still tries to work on it own
<warren> thl, putting together official trainer/sponsors at the different major engineering offices too.
<thl> anyway, it's not a big deal; but you maybe should keep it in mind
<abadger1999> We need to talk about what we want to present to packagers in terms of packagedb/build sys interface at some point.
<f13> thl: sure, we welcome anybody else to sponsor a RH employee, but we're not oging to wait forever.
<dgilmore> thl: ive sponsored a couple of RH guys
<thl> f13, then *ask* community members if they want to sponser people
<dgilmore> and will sponsor some more that ive heard of before
<thl> especially now during the merge
<nirik> I'd be happy to sponsor any of the rh guys that I approved packages for... but don't think any of them have applied... should I tell them to?
<tibbs> I am certainly willing to sponsor Red Hat folks.
<thl> then we can later at least say "hey, you could have sponsered somebody, you didn#t, thus we sponsored him"
<f13> thl: they apply for cvsextras, any sponsor is welcome to take them up on it.
<thl> f13, that's not enough IMHO
you need to ask people
<f13> nirik: if they haven't already, then yes.  Many already have accounts, but are still going through the review process
<nirik> yeah. ok. Will ping them...
<bpepple> Ok, anything else on the merge?  Otherwise I'll move on.
<warren> one more note
Everyone having FAS accounts will be important to later simplify things like owners.list
<tibbs> I thought that was mandatory in any case.
<f13> how can you manage a package in the external world without a FAS account?
<warren> tibbs, yes, but to make it possible sooner
<bpepple> I'll go ahead and skip the co-maintainer topic since thl sent an e-mail about it earlier today.
<abadger1999> warren: Are you talking about FAS email==bugzilla email?
<thl> wait
<notting> one thing about the current owners.list format - i'd like to list multiple owners in the owners section - is everyone OK with just going ahead with that and breaking any tools as we come across it?
<abadger1999> Or just existence of a FAS account?
<thl> bpepple, I'd like to have feedback from those that are around
<rdieter> notting: +1
<bpepple> thl: no problem.
<abadger1999> notting: I'm not.
I have problem with it.
<c4chris> notting, fine with me.  I need to work on my package status script anyway to take into account the new review process...
<nirik> notting: what do multiple owners mean? co-maintainers? or ?
<notting> nirik: right
<abadger1999> Packages have a primary owner.
<notting> abadger1999: first one in the list ;)
<warren> abadger1999, not necessarily, but I'd like to list FAS accounts in owners.list and do translations rather than have e-mail addresses in there.
<thl> notting, and how is that and improvement to that we hae now (just wondering)
<abadger1999> notting: Okay then.  It's better than what we have now -- where initialcc can be for both watchers and for co-maintainers.
+1
<warren> bugzilla would assign to the first listed owner, but other tools could be smarter about it.
<notting> thl: elevates them from initialcc to 'ownership' (can edit acls, automatically gets all commit notification,etc)
<warren> ACL generation, mail notifications, etc.
<thl> notting, ahh, okay, thx for the clarification
<bpepple> sounds ok to me. +1
<abadger1999> warren: I see.  So not just, have a FAS account, but use the FAS account to reference the person everywhere.
<tibbs> +1; my tools will break, but no big deal.
<warren> abadger1999, yes, that would simplify things everywhere.
abadger1999, (although FAS account name still shouldn't be the unique key)
<f13> notting: +1, I'm not a subscriber of the owners.list API, so break away! (:
<notting> warren: for later use, if we do this, might be able to go to owners == FAS account, initialcc == email.
<nirik> +1 from me, broken tools can be fixed... as long as it adds data and helps things in the longer term.
<warren> notting, we could even do both.  if the name in initialcc isn't an e-mail address, then assume it is a FAS name.
<jeremy> yeah, that's probably fine and pretty straight-forward to fix up the bugzilla script
<tibbs> No '@' => FAS name.  Sounds like a great idea to me.
<rdieter> wait, notting had a good reason?  I thought I was voting +1 for willy-nilly.  I take it back.  (:
<abadger1999> notting: While you're at it, could you encapsulate owners.list in a python API?
<notting> abadger1999: *cough* it is
abadger1999: CVSROOT/admin/owners.py
<f13> neat
<warren> owners.list should end up in a database, not a text file
<notting> mind you, it may not be a *good* python interface
<nirik> well, owners.list will go away once the package db is in place, right?
<notting> ok, will send mail and schedule the switch for monday-ish
<f13> thats the plan.
<bpepple> notting: great, thanks.
--- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership
<warren> notting, which switch?
<warren> bpepple, why is this still on the schedule?  All of the other work enables this.
<notting> warren: multiple owners in owners section, as opposed to listing the co-maintainers in initialcc
<warren> notting, k
<bpepple> warren: you mean co-maintainship?
<warren> bpepple, huh?
<f13> <warren> bpepple, why is this still on the schedule?  All of the other work enables this.
* f13 thinks warren needs less threads
<bpepple> warren: which item?
<thl> seems everone is confused :)
well, notting wrote my proposal is to long
some fesco members (three iirc) read it and they did not complain
I tried to solve some fundamental problems we have
yes, it got a bit long
but the policy itself is not short
and the other stuff is just guidlines
<rdieter> thl: fwiw, I think it's good.
<thl> as IMHO having a repo where the co-maintainers ships workd differently for each pacakge
<bpepple> thl: I think it's good also.
<thl> or is not defines at all would be bad and cofusing
<nirik> FYI: http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership
<thl> thx rdieter, bpepple
<thl> other opinions?
notting said it's to long
but as I said: it tries to solve many problems
that what co-maintainership as a whole always was about afaics
I even left the "co-maintainership can replace sponsership" part out
but I think that is something we need
<notting> thl: my concern it's a lot of manifesto (co-maintainership is good, here's why, here's what problems it may solve), and less policy
<c4chris> having such a document is probably useful, but is it really policy ?
<thl> notting, the "here's why" is not part of the policy iirc
<c4chris> i.e., are we going to pounce on maintainers that do not show much enthousiasm in tracking down co-maintainers?
<thl> that part of the schedule page, the policy starts below it
c4chris|w c4chris
c4chris, we don't send out nijas
c4chris|w c4chris
<warren> at least not anymore
<thl> but saying "you should try to find at least one" imho should bring most to work
warren, no, we have the orbital laser :)
<c4chris> thl, yes, precisely, so can we actually have a policy that says "thou shalt seek co-maintainers" ?
* nirik likes it overall...
c4chris|w c4chris
* f13 doesn't like a policy that forces one to find co-maintainers.
<thl> c4chris, I thought you didn't like "The maintainers should actively work towards getting at least one co-maintainer" part
<f13> I like encouraging it, and explaining why, but forcing you to have one is not kosher IMHO.
<rdieter> f13: it doesn't, not my reading of it, anyway.
<nirik> should we wait for the package db to push for co-maintainers on everything? otherwise the fedora-cvs-needed ? is going to go crazy... or could. ;)
<c4chris> thl, yes
<bpepple> f13: I don't believe it forces maintainers, but does strongly encourage.
<rdieter> See title: "Encourage..."
<thl> so how to get further with this?
<tibbs> All I care about is that maintainers understand that the project needs to have something in place in case they get hit by a bus; that's all.
<nirik> If there is a email generated with packages that are not co-maintained, it should be sorted by highest # of open bugs to lowest. ;)
<c4chris> ok, recommendation is fine, forcing is not
<warren> fedora-cvs is ONLY a cvs admin attention grabber
<notting> what i'd like to see is simply two or three sentences that can easily be added to the maintainer role as policy - right now that page is 10x longer than the gettysburg address, which is not conducive to having all maintaners easily read and digest it.
<bpepple> thl: should this be sent to the mailing list now?
<nirik> warren: yes, but if I am to add a co-maintainer, and can't edit owners.list, how can I do so?
<warren> nirik, the latest draft says how
nirik, use the existing review ticket (closed is fine), write a new comment and set fedora-cvs?
<thl> bpepple, I'd want to have a mostly buy in from FESCo before it send it again to the list
<bpepple> thl: yeah, I can understand that after the last time this went to the mailing lists. ;)
<thl> notting, I try to solve more with this stuff
<nirik> warren: right, but my point is that won't scale for co-maintainers requests if there are a ton of them at once...
<rdieter> nirik: why not?
* thl has to leave soon
<notting> thl: is it possible to split out the different problems you're trying to solve?
<thl> most of then interact with co-maintainership
and that takes a lot of time
<c4chris> thl, (sorry, me is half sick so maybe I do not make too much sense...) I just meant to say we wouldn't be able to enforce a such policy...
* rdieter thinks it better to publish *something* sooner, rather than waiting until the document is perfect.
<nirik> rdieter: if it's announced that having co-maintainers is strongly encouraged and some large fraction of the 2800+ packages decide to do so, won't the cvs admins get flooded?
<thl> rdieter, +1
<bpepple> rdieter: +1
<thl> rdieter, we can always adjust stuff
<warren> nirik, my latest draft says that too
<c4chris> rdieter, +1
<warren> nirik, if there is a bulk request, talk to a cvs admin directly so the mass changes can be scripted.
<rdieter> nirik: cvs-admin don't block anything, primary maintainers still control the acl's mind you.
<thl> c4chris, I don't think we really have to enforce that
<warren> nirik, and yes, primary owner can edit the ACL, or remove the ACL.
<nirik> warren: ok, fair enough...
<c4chris> thl, k  I'm fine with it then
<thl> c4chris, that will come on its own -- if somebody has no co-maintainers and someone wants to become one and gets rejected he can complain on the list
<notting> rdieter: i just think something simpler along the lines of 'we encourage co-maintainership; listen to those who ask, or troll fedora-maintainers.' is fine. i think the page as posted is just too long/overreaching to be used as a policy/announcement
<thl> c4chris, kind ov "public encouragement"
s/ov/of/
<rdieter> notting: and I don't disagree, I like your idea of having a short/concise version, and possibly linking to the more verbose one.
<c4chris> thl, sure
<thl> rdieter, the short one is just the policy section
<warren> I don't see why "encouragement" is such a big deal.  Creating the infrastructure to allow this easily is the hard part.  Encouragement can be a very natural and easy thing at that point.
<thl> four paras
<rdieter> I just don't think we should block on *just* that.
<abadger1999> rdieter: +1
<thl> we also need the co-maintainerstuff now for real
<warren> why?
<thl> otherwise EPEL will get  hard
<warren> EPEL owners are different
EPEL owners can come to agreements with Fedora owners
<notting> thl: but we have 'enough' of the infrastructure of that for now
<thl> as people start to raise questions what to do if the primary FEdora maintainer doesnt want to maintain the package in epel
<warren> Just write down the policy regarding that for EPEL, and deal with it on a case by case basis if there is a dispute.
<thl> the co-maintainerstuff solves the interaction between FEdora and EPEL, too
actually I'm not going to work much more on this
<warren> In the majority of cases, EPEL will just be the same owner.  Or Fedora owner doesn't want to participate, should that stop someone else from doing EPEL?
<thl> either people like the direction, or I'm done with that and leave it for somebody else
I invested a lot of time in that
and a lot of feedback from FESCo members
and getting told now that it is unwanted feels sad
especially if at least four or five members agree with the direction
while one or two dislike the length
afaics
<f13> its not that it isn't wanted, it's just a bit heavyweight without perhaps making i tmultiple documents
<rdieter> thl: what do you want?  a FESCo blessing?
<thl> rdieter, now? no
more a: yes, this is the direction we want, now lets work on details during the next week, and then ratify it
<warren> thl, I suspect that it may have good ideas, but as the infrastructure evolves we may realize exactly what is needed and streamline it.
<thl> re
<rdieter> thl: ok, done. (:
<warren> for example, some policy need not be written if infrastructure enforces it, or packagedb guides it
<abadger1999> warren: In that case, we should approve it and revisit it as the infrastructure comes online.
<warren> I guess so
<bpepple> How about we vote whether to continue in the direction thl has been working on?
<c4chris> I think the direction is fine, and I'd approve it for now.  We can always revisit later if needed.
c4chris|w c4chris
c4chris|w c4chris
<warren> As long as it isn't set in stone
<bpepple> c4chris: +1
<nirik> c4chris: +1
<thl> warren, do we ever set something in stone?
we never did that until now iirc
* rdieter though all of our wiki policy statements were backed up by being etched in stone tablets.
<abadger1999> c4chris: +1
<rdieter> +1
<warren> rdieter, battery powered with lights too.
<c4chris> the etching was done with lasers...
<warren> from orbit
OK move on. =)
<thl> so I take this as "the direction is okay and we sort out details over the week and get back to it next meeting"?
<rdieter> yes, please.
<c4chris> yes
<bpepple> thl: yes, I didn't see any '-1'.
<nirik> thl: yeah, perhaps a "here is the policy" and link to the longer stuff could be done.
<thl> k, thx guys
* thl will now leave
thl should have left 25 minutes ago
<thl> cu
<bpepple> Ok, moving on....
<bpepple> thl: later.
<c4chris> see ya
--- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- Parag Ashok Nemade
* notting is still trying to figure out what 'the direction' is
<c4chris> didn't see much discussion on the list...
c4chris|w c4chris
<bpepple> c4chris: agreed.  should we table this for next week?
<c4chris> notting, I think simply "we wants more co-maintainers..."
<warren> bpepple, +1
<bpepple> ok, moving on...
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<abadger1999> Did warren's sponsors request ever make it to the sponsors email list?
<notting> c4chris: that i have no problem with. just not sure why we need more than the section that's currently listed under 'digest'
<warren> abadger1999, hmm, I might have sent to the wrong list.
<nirik> could someone with the needed perms in the Package space on the wiki update with things that were passed? It's confusing when the guidelines are out of date.
* bpepple isn't sure what list it was on/
<warren> Parag and rvokal are two of our regional office sponsor/trainers
The sooner we can get them sponsor access the better.
<tibbs> I wanted to see how rvolkal dealt with merge reviews.
--- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- Parag Ashok Nemade
<abadger1999> It was on fesco's list.
<warren> rvokal had a long talk with jkeating on the topic
rvokal also sat in one of our meetings on the topic
I'm sure this will work out
<tibbs> I will admit to having  some bad experiences with panemade early on.
I haven't been following his more recent review work so I won't speak against him.
I know he's been doing a tonne of work lately.
<warren> rvokal is needed sooner than Parag.  We already have another sponsor in APAC.
rvokal is in our Czech office
<nirik> +1 on parag for me... it took him a while to get up to speed, but I think he's doing quality work now...
<notting> warren: why is *sponsorship* needed per geo? to drop by desks to explain things, or something else?
<bpepple> I'm fine with trusting warren & jesse's opinion on rvokal.
<warren> notting, yes
<tibbs> rvokal dealt with one of the merge reviews with "I'll look at this in a couple of weeks; patches appreciated".
<warren> notting, if engineering is telling RH engineers they need to get FAS accounts and to get sponsored, we should make it easy with designated people.
<tibbs> Which is fine, I suppose, but sort of misses the point of few reviewers and thousands of packages.
* nirik would add disclaimer for panemade, that I am his sponsor.
<warren> notting, especially useful for new employees to get them up to speed... like in Czech.
<rdieter> rvokal: +1
<nirik> so are people ready to vote? or want more time to review/consider?
<abadger1999> I think vote should be postponed.
<warren> I think enough people gave +1 on rvokal, do we want to wait on parag?
<notting> random: is there a way for non-FAS-yet people to get a list of sponsors?
<abadger1999> Until the intention to make them sponsors goes to the sponsors list.
<warren> notting, yes, working on that.
<bpepple> warren: I think we should probably wait on Parag.
<warren> agreed
<c4chris> abadger1999, ah right, would avoid ruffling some feathers...
<warren> are we OK on rvokal?
<bpepple> +1 rvokal
<abadger1999> Not because I think rvokal and parag are incapable, but because it's an aspect of community to use the established rules.
<warren> abadger1999, we should wait on both?
<abadger1999> yes.
<warren> which list btw?
I'm confused.
<abadger1999> It goes to all the sponsors.
ahalsey abadger1999 adrianr
<bpepple> abadger1999: maintainers list?
<warren> If FESCO is the voting deciders, sponsor list is only "anybody have any problem with this?"
<abadger1999> Anyone know if that's just an alias?
<cweyl> abadger1999: I think it is.
<warren> sponsor list is just an alias generated by FAS
<nirik> yeah,  it's just an alias...
cvsextras-sponsors@fedoraproject.org
<warren> OK, i'll post that now.
<abadger1999> warren: Yeah -- it is advisory, but it's the same concept as having the FAB list where anyone can give input even though only a few have real power.
<warren> Do we wait until next FESCO meeting to approve either?
<tibbs> I have to go AFK for a few minutes, sorry.
<warren> Or if no objections to rvokal, we just do it?
<bpepple> warren: probably for the best.
<warren> rvokal is a bit more important, because we have many new engineers near him
<notting> warren: re: rvokal, we do already have a sponsor in .cz ;)
<warren> notting, tmraz, but he wasn't in the meetings
I move that we just approve rvokal for sponsorship, this is unnecessary bureaucratic baggage slowing us down.
<rdieter> I'm ok with "just do it" wrt rvokal.
* bpepple is fine with rvokal also.
<warren> I'll post about Parag now
<c4chris> k
* nirik gave +1 for rvokal on the list, and is still +1 now. ;)
<warren> hmm, what is parag's FAS name?
<rdieter> please post about rvokal too, for posterity and feedback.
<notting> +1 to rvokal if we're voting.
<warren> rdieter, doing so.
most of FESCO voted +1 for rvokal, I'm posting anyway, and upgrading him.
<abadger1999> Core+Extras merge is a sensitive time.  We don't want to appear to be rubberstamping Red Hat employees in.
<warren> abadger1999, I'm afraid the sponsorship of RH employees may appear to be more of a rubber stamping than this.
<bpepple> abadger1999: we do need to make some allowances due to the merge, due to how quick it is approaching.
<cweyl|work> abadger1999++
<rdieter> abadger1999: we can always revoke it if dirt turns up on the lists... (:
<bpepple> rdieter: +1
<warren> abadger1999, getting the trainers in place sooner is an attempt to make this less of a forced thing. =(
<abadger1999> rdieter: +1
<nirik> warren: parag's fas name is paragn
<bpepple> Ok, so summarizing rvokal is approved, and next week we'll vote on parag.
Moving on since it's getting late....
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<bpepple> Anything to report from the packaging committee?
<notting> bpepple: BuildRoot AAAARRGHAHGAH.
<nirik> I'll echo again that someone should update the guidelines on the wiki with things that have passed in recent weeks... is spot the only one with acls for that area of the wiki?
<rdieter> nirik: everybody in the PC is acl'd. (:
<spot> no, everyone has access on the PC
<bpepple> notting: yeeks, don't even want to hear about the buildroot. ;)
<spot> and the people responsible for writing them are noted
<tibbs> OK, back.
<abadger1999> No.  But we've been depending on the people who drove the guideline change to make the changes.
<spot> which, admittedly, is mostly me
i'll do my bits this afternoon
<warren> mail sent
<nirik> yeah, buildroot stuff == anoying. ;(
I hate blocking packages due to just buildroot... but it's kinda submitters fault if they refuse to change small bits.
<spot> ok, PC stuff
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
the Jpackage naming policy was approved
Also, the spec file naming clarification was approved
<warren> %{name}.spec must be the spec filename?
<spot> warren: yes
unless its a special case (like gcc)
<tibbs> Existing packages are grandfathered so as to not lose history, though.
<notting> history can be 'fixed'
<tibbs> Well, I know it can be hacked around in CVS, but we didn't want to assume that we could do that or that it wouldn't break other things.
<warren> notting, history is written by the victors.
<notting> warren: history is written by those with shell access to the cvs server.
<tibbs> The policy has a note about what happens when we get an SCM that makes renames easy.
<abadger1999> notting: If you want to propose to jakub and others that you'll make the necessary changes in CVS, then there's no problem.
The specs can become %{name}.spec and we can remove the package from the exception list.
<notting> abadger1999: maybe just add 'if you want your spec renamed with history, contact the cvs admins'
<spot> ok, thats it from the PC
<notting> spot: what are the chances that we could get 'don't care about the buildroot, patch rpm instead' through the PC?
<abadger1999> frankly, I thought it was too small an issue to fight over grandfathering a small number of packages.
<spot> notting: if you can get rpm patched, the PC will happily forget about buildroot
but its more likely we'll say "for packages < FC-7, use old buildroot"
"for packages FC-7 >, don't set buildroot in spec"
<warren> notting, does that handle if they want to check out an old version?
notting, (it actually works in such cases)
<spot> "for packages == FC-7, do the batusi."
<notting> updates!
* rdieter needs food, badly, needs to run soon.
bpepple also need to leave fairly soon.
<c4chris> k, wrap it up, I say :-)
<bpepple> spot: do we need to vote on the latest proposals, or can it wait till next week?
<warren> Where should I post the updated CVS procedure in the wiki?
I guess CVSSyncNeeded can point at it
* nirik looks ahead to posting a comment to Matthias'es open reviews and having him not be happy.
<tibbs> As long as it's linked from cvssyncneeded so that it's completely obvious that the procedure has changed, I think we're OK.
<rdieter> voting sooner is better, so things end up in the guidelines faster.
<warren> tibbs, k
<nirik> warren: also, new package process might need updating?
<tibbs> Let me look at the long contributor process document.
<bpepple> We should probably wrap this up...
<warren> nirik, I think so, is that protected by spot?
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras
<abadger1999> bpepple: It's a case of if nobody yells, it'll be considered ratified.
<warren> wrap up, people need to go
<c4chris> abadger1999, yup
<bpepple> abadger1999: great.
<tibbs> warren: http://fedoraproject.org/wiki/Extras/Contributors will need updating.
* 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