Extras/SteeringCommittee/Meeting-20070215

= 2007 February 15 FESCo Meeting =

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)

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