Extras/SteeringCommittee/Meeting-20070222

= 2007 February 22 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)

awjb

 * Andreas has decided to step down from FESCo due to time constraints with his university work.

Core/Extras Merge

 * FESCo ratified the new Package Review process. For more details refer to https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00380.html

Co-Maintainers

 * FESCo ratified the co-maintainers guidelines. http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership

Sponsor Nominations

 * Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, and Chitlesh Goorahwas were nominated and accepted as new sponsors.

Packaging Committee Report

 * FESCo didn't have any objections to the Packaging Committee's guidelines regarding:
 * SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl

Log
--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process dgilmore is here I'm here nirik is here. hello yo Since it's an init process: rdieter: ......... OK FESCo meeting ping -- abadger1999, awjb, c4chris, f13, jwb, spot, tibbs, warren It's a busy day here at work; I may be in and out. spot: didn't expect you to be here since your overseas. spot is committed to the cause. hey spot: good flight? a real tropper, spot is. trooper, too. dgilmore: the flight was fine, but i can't sleep on planes, so i slept all day and woke up a little while ago Ok, looks like about everyone is here, so we can probably get started. --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- thl -- okay for everybody if the EPEL-SIGs works more on its own and reports to FESCo spot: ahh I cant sleep on planes either so i feel your pain bpepple: +1 :-) sounds fine to me hmmm i thought we already had agreed to this my mail to fedora-devel about EPEL got 0 responses +1 from me... I think it's good to have it in a SIG... Just Do It dgilmore: I though so also, but regardless it's a good idea. just do it: +1 go forth and multiply. or something. +1 from me +1 I thought that's how it was working already, so +1. any '-1'?  otherwise consider it done. thl: 0 replies means everyone likes it, obviously. (: tibbs, I thought that, too :) rdieter, agreed :) I don't recall ever seeing the message, but there are so many lists to keep up with. thl: anything else in regard to the EPEL-Sig? bpepple, not that I know of bpepple, move on ok. --- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process -- warren bpepple: just that we are having our first meeting this wekeend Any further objections to the review with flags process? FYI, of the 1085 core merge reviews, 18.4% have been touched... dgilmore: I'll put a note in my summary about that, and send it out tonight. No objections here. one modification: fedora-review- means final no, not temporary no warren: the last version seemed good to me. so fedora-review? is exactly the equivalent of FE-REVIEW warren: flags seems fine as long as its used This process is *BOTH* for Merge and new packages and we have to get rid of the tracker bugs the tracker bugs is already removed from new tickets filed through the template interface warren: +1 from me. We should also come up with a plan for all the reviews currently "in transit" The only question I have is what replaces a query on FE-NEW. tibbs: componet Fedora Review and flags " " ? or assigned to nobody@fedoraproject.org. Or that cached review page, I guess. tibbs, the best way to do that is the cached status page we should have more cached status pages tibbs, I not RE not match [+-?] they are really fast s/I/I use/ The cached pages should not be run outside of the project, though. Otherwise we can't expect people to depend on them. that was only a test It seems successful enough to make it a regular FI thing. implementation question: assuming FESCo likes the new review procedure, can we have an effective date of a week or so from now? give people time to get used to the new procedure, communications, etc, etc http://rubenkerkhof.com/review is all I've been using for the merge reviews. tibbs, yea I thought mmcgrath was going to make them run on fp.o somewhere cweyl: given the level of confusion, is waiting worth it? can't we just tell people as they go to look at the new procedure? (I even rewrote the stuff ib Python to that end) I think we just need to put our foot down and say THIS IS THE PROCEDURE warren: +1 people have been confused by the old process and various versions of the new process warren: +1 nirik: the confusion (to me at least) seemed to stem from the fact stuff was changing cweyl|work cweyl this has been especially frustrating for the RH engineers people were in the middle of things, and all of a sudden they didn't know what they were supposed to be doing cweyl|work cweyl I move that we just ratify it, update the documentation and announce widely. for the merge reviews, we will need to go in and change any in state "-" to state "?", for any in extras, we will need to remove blockers and change state as needed. a date effective would answer all those questions -- and even people who lag a day or two in reading all those lists should get it nirik, trivial nirik: I could just be dense here, but I don't see a component Fedora Review abadger1999: Package Review abadger1999: it's under fedora-extras cweyl, people have already been using the new process, or close to it warren: but not everyone, and really they should just be using it for the merge reviews I think we don't need a warning or transition period, because people were already too confused. cweyl: thats part of the problem... some extras reviews have been using the merge procedure, some not, it's a mish mash Just put foot down and make it so. warren: that's where the confusion came from. "here's this new process!" but not so clear on when, where, why, etc THIS IS IT. ok, how about we vote of ratifying warren's proposal, and then we can decide when it becomes effective? and that's been effective before :) im fine with the flags proposal for the love of all that is holy, let's ratify the policy, make it so, just do it: +1 +1 from me. All good. +1 VOTE: Ratify the proposal? (Independent of when, which is the next vote) +1 +1 +1 I say for 1 week both old and new is fine after that new only +1 aye. +1 (i just want the confusion to end) +1 OK... is that done? +1 done, stick a fork in it. I don't see any one objecting, so consider it ratified. I'm here. OK.  VOTE: Effective immediately?  (Does anyone object enough to give a -1 on this? I think we're better off with immediate.) +1 +1 +1 +1 +1 warren: -1 +1 erm, +1 with grandfathering of existing reviews changes without enough lead time for communication are a continuing disaster :/ enforced or not enforced? jeremy: exactly! +1 What if we told people "DO THIS", but if they happen do the the old thing, that's OK until March 1st? jeremy: so it would be "use whatever unclear procedure you think we were using" until the new effective date? We can politely remind them as we see it. ok, I see 8 for immediate, and 1 for not. +1 warren: That I would be okay with.. +1 warren: +1 warren, yes OK... so the plan is.... DO IT, and politely remind. warren: yeah, I assumed there will be people using wrong procedures until they know better, but the new one should be effective now. warren: sounds good. the transition period should be stated in any communications warren: anything else on the review process need to be discussed? Yes. before we can say "this is it, effective now", we need to have all of the wiki stuff ready to go and udpated to reflect it Do we keep the FE-NEW, FE-REVIEW, FE-ACCEPTED as-is? jeremy, +1 warren, yes, keep I could ask dkl to get rid of the tracker bugs and automatically adjust the flags to match the current procedure. This can be done with no mail. at least until pkgdb is ready and loaded, then I don't care That way querying it is consistent. FE-ACCEPTED becomes fedora-review+ warren: at least until the transition period is over, then I'd say get rid of the tracker bugs FE-REVIEW becomes fedora-review? if it can be done without a flood of emails and c4chris can adjust his scripts I would say change them... OK, we'll discuss removal of tracker bugs and fixing the flags next week. (the lack of FE-REVIEW should be an immediate clue to anyone after that point that something has changed :) ) I'd like to lear a way to get info on who changed what flag when in batch mode s/lear/learn/ warren: so that we can change hte review policy at least once a week right? f13, what do you mean? c4chris, hmm good point warren: if you go forward with things now, then in a week decide to stop the use of blocker bugs, thats yet another change to the proceedure I'm in favor of just stopping the old procedure now and telling people as we see it to use the new procedure. But some people here want a transition period. thats entirely beside the point you're driving an incomplete change to the review process through one that you're going to change again, in a week's time. warren: i think f13's point is *whatever* we're doing, he wants it decided completely at this meeting f13, documented procedure would not reflect the old procedure at all during this week. what's the rush to kill the trackers now? the procedure just agreed to here doesn't use the blocker bugs at all... removing them after the transition period it's just cleanup. right? Killing trackers has nothing to do with ratifying the new review process. notting: correct. rip the bandaid off all at once, not a little bit each week. just add the flags if you wish, but no need to kill the trackers *right now* Killing trackers simplifies what people see, and makes it easier to query things in a consistent way. warren: the new process, do you still use blocker bugs? NO none ok. then disregard me. OK, schedule: Next week we talk about what to do with tracker bugs meanwhile I'll talk with dkl about feasibility. k warren: ok, if there's nothing else we can move on. Last review topic: Queries and cached pages. Is cached pages enough? Do we need also canned queries? rdieter: I was confused. I thought using FE-NEW/ACCEPT/REVIEW was still part of ht eprocess, and we'd revisit that next week. I was wrong. warren: canned queries would be nice question: for reviews that are "in flight", should people remove the existing blocker bugs when they add the flag? or leave them? f13: yeah, I typed too slow. (: nirik: I'm in favor of leaving them. nirik: I say just leave them until they're mass-removed Does anyone want to own canned queries and cached pages? This would involve 1) figuring out what the queries are, putting them on a wiki page 2) working with FI with a RFR to make cached pages a permanent thing. ok, that should be made clear in the wiki/wherever we announce it... so people don't remove them. The code for cached pages is pretty much done, you only need to customize it, and maybe talk to mizmo to improve the look. warren, I can take that cool thanks c4chris. I just saw recently that you can make personal queries public... was meaning to look and see if that would help any. OK, anything else we're missing for reviews? Besides another 500 reviewers, you mean? warren: what do merge reviews do when the review is over?  close the bug? bpepple, I would like to talk briefly about RH sponsors and internal RH concerns sometime warren: do you want to do when we look at new sponsors? warren: the question came up a few times, is it documented somewhere? f13, it actually doesn't matter, if fedora-review+ is set, we're fine. But that could be better spelled to mean "CLOSED only if you have fixed and tested the binary RPM."? in principle, CLOSED means package ready in repo no, it's a valid point. we should have a documented procedure for a) the case where people want to 'move early' b) the case for when we do the mass move warren: closed when built for rawhide? bpepple, prior to, yes warren: ok. notting, f13: It needs to be spelled out explicitly in writing, the details of which we should discuss separately from this meeting? warren: sure probably, yeah. would need sponsorship, etc. stuff too ok, sounds like we're finished on this topic, so we should probably move on. sponsorship is another aspect that I've been working on, which is part of what I want to talk about when we're on that topic here. --- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- thl thl: anything to report on this? bpepple, well, it got discussed on the list a minor thing was adjusted so IMHO we should just make this effectie is it to the point where FESCo can vote on it? effective I think so Has everyone read it? http://fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership we can of course adjust eerything later, but I think this is it for now I still think it's just so incredibly long, but I don't find anything to disagree with. I know that some maintainers will bristle at the section about maintaining too many packages. thl: mildly concerned about the last entry in 'Policy'; i could see refusing a maintainer for EPEL on technical merits even if they're willing I want to prevent that we run into a situation where a Fedora packager tries to prevent that a package gets build for EPEL if you have a better idea how to circument that: I'm open tibbs, nearly nobody complained about the "section about maintaining too many packages" I think that section is important thl: maybe just 'can't block co-maintainers for distributions he does not want to support on that basis alone.' I recall flames on list about it. I guess that's what you mean by "nearly nobody". tibbs, yes (the flames were mainly in the first round) notting, sounds fine Ok, let's vote on ratifying this, taking into account nottings suggestions. But my point was that I don't disagree; I just think some people will. +1 +1 +1 +1 +1 +1 +1 +1 +1 thl thimm thl: ok, I don't see any objections so consider it ratified. thl thimm thl: anything else? otherwise I'll move on. --- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations bpepple, sorry, was in the wiki bpepple, moing on is fine thl: no worries. warren: you want to talk about sponsors? OK Red Hat has many engineers who do not yet have FAS accounts or sponsorship. I'm working on documentation to make it very obviously clear exactly why and how to do this. Furthermore I'm trying to be sure that all regions and offices have designated sponsor trainers. Some of the proposed sponsors within RH might not fully qualify for sponsor access given traditional requirements. Yes, that's been my main issue. However I ask FESCO to accept this, because it is part of their job requirements to FOLLOW THE WRITTEN GUIDELINES. Sponsors are responsible for ENFORCING THE WRITTEN GUIDELINES. Speaking of sponsor nominations.... Furthermore we need all of this done sooner than later in order to make RH engineering less cranky about all the big changes in merging for F7. warren: i see it this way. they mess up we are going to scream at you Things might not be perfect at first, but I think we'll gradually shift everyone in the right direction. dgilmore, that's fine. dgilmore: scream at me instead warren: Unfortunately we've seen examples of those who simply don't want to follow the guidelines, and loads of flames about it. The big news here, is this implicitly means FOLLOWING THE WRITTEN GUIDELINES is a part of the job responsibility for the RH engineers. Aside from the buildroot issue? Ah yes, please scream at jeremy instead. All kinds of things. .la files, static libraries, directory ownership are just those that I remember from fudcon. jeremy, thanks. =) warren: np jeremy: it will probably go to you and notting also jeremy is the official fedora ninja after all. tibbs, I agree there are concerns. How widespread would you think is lack of cooperation in following guidelines? tibbs: removal of static libraries really has to be done with a lot of care.  I've already been bitten a couple of times now due to over-enthusiastic nuking of static libs from a package previously in core :-/ I can't say, as lately there's just too much review traffic for me to follow it like I used to. jeremy: Which is why this stuff requires hard work, not arguments. I haven't noticed too much of that, but it could well be there... as long as sponsors are onboard, to police those they sponsor... (: jeremy, would you want cases where RH engineers disagree with guidelines forwarded to you to handle? Also, there are a lot of reviews with no answer from the "owner", but that might be due to RHEL5 busyness? sure! and we can then go from there nirik: + rhel updates Bottom line is that I'm happy to accept RH people that are well-trusted by the other RH people as sponsors. rdieter: I agree. But that's why sponsoring Red Hat people because we need someone in the $GEOGRAPHICREGION office isn't the greatest. tibbs, jeremy: perhaps as a policy matter SOMETHING has to be decided regarding buildroot, because that is just a STUPID WASTE OF TIME to deal with on an individual level. How many times do we have to decide the same thing? buildroot = the value in the guidelines. We've voted on it like three times now. warren: its simple we agreed on a buildroot use it I can't recall any merge reviews where they refused to change buildroot... formerly extras I have about 3 blocked on it now. What to do about Extras people who refuse to use it and say they will change it back if it is forced upon their spec files? buildroot was just revised and changed by FPC ... What to do about RH engineers who do the same? thimm: that didn't pass the week timeout thimm: the mktemp version failed. What's a "week timout"? thimm: we even withdrew it because it didn't work. to be entirely honest -- the entire buildroot argument seems like insanity to be spending as much time on as has been spent Before we become to involved with the buildroot, how about we look at this week's sponsor nominees? jeremy: then tell nasrat to start building new rpm ;) could decide something, but what about the people who refuse to do it? So why make any buildroot mandatory? jeremy: indeed.  we agreed to something use it and move on thimm: after FPC votes on something, FESCO and COre was given a week to raise objections before we put it into stone. Sure, this is stupid... but what? f13: ut it was not discussed at all last week? /ut/but/ thimm: I wasn't in the meeting. And why this buildroot matter at all?  Why can't it be ignored by the buildsys and overridden? thimm: it wasnt brought up in the FPC report warren: that's the long-term plan. warren: because it's a guideline to help out of buildsystem building apparently. Could we table this until the Packaging Committee report later in the meeting? OK. dgilmore: but that does not make it dropped, right? bpepple: yes So, individual sponsors? Let's start with Parag Ashok. +1 +1 +1 +1 +1 I sponsored him long ago, +1 from me. ;) +1 +1 +1 Alright, Parag is a sponsor. next up is Andrew Overholt. 0 +1 +1 I've reviewed his packages before and he was responsive. I haven't seen much of his reviews, but given all the above and that he's vouched for +1 +1 I looked at some of his java packages and they looked good. +1 +1 The java team seems to have respect for the guidelines. +1 +1 Andrew. Just from a look at a few packages and his mailing list posts. +1 Andrew ok, I don't see any '-1', so Andrew is a sponsor also. Next up is Thomas Fitzsimmons. +1 +1 (based on Ville's recommendation, who worked with him on jpackage) What's his email address? fitzsim@ +1 +1 +1 +1 +1 +1 +1 +1 +1 I've done some of his packages as well. Alright, so Thomas is a sponsor also. Next up is Chitlesh Goorah. +1 +1 here also. +1 +1 +1 from me. +1 +1 Ok, Chitlesh is a sponsor. Next is Fernando Nasser. 0, I'm not familar with his work. +1 Anyone have a quick BZ link to fnasser's reviews? 0 Fernando Nasser was a Ville recommendation and he's another java team member +1 fernando helped write the jpackage "exception" for FPC I have to admit I haven't seen Fernando's work 0 - I haven't interacted with him I don't think Want to wait until next week for Fernando? +1 Yes. warren: yeah, that sounds good. Wait. +1 next week. OK Ok, let's hold off on Fernando till next week. fnasser seems to have no completed package submissions. warren: can i ask a question? why do we need three java-specific sponsors? notting, we don't need, but it doesn't hurt. That's it for this weeks new sponsors. Moving on....... sponsor rank is not just a measure of "we need sponsors" but also that we trust that they follow and enforce guidelines to others. --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop ok, one sec, lemme pull the notes tibbs: Did your questions about rvokal get resolved? We approved http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl abadger1999: Yes, I'm fine with rvokal. Also, we added a "should" (not a MUST) for http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps Last but not least, we're still working on the whole buildroot nightmare. More to come. jeremy: you should update FileDeps with the sqlite sizes spot: thanks. spot: we really need to have better updates from the packaging committee to "the world"... some of the changes are starting to catch people by surprise and then it's coming back to me jeremy: you're right, and we're working o nthat MAybe through the fedora-maintainers-announce list= jeremy: hopefully the new job will put me in a better position to be able to be more "announcy" spot: k. just wanted to make sure it was mentioned. Alright, anything else regarding the packaging committee? Otherwise I'll move on. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras One quick item: Should membership in fedorabugs require cladone? I have a question. Since we're running late, I'll skip the cvs-import & F7 prep for this week, and go to the free discussion. nirik: maybe mebership in fedorabugs should require (cvsextras || fedoraqa) notting: indeed i.e., some sort of demonstrated commitment to the project nirik: Once mether explained that fedorabugs is necessary for triage, I'm not certain that cladone should be a requirement. After all, anyone can add a patch to bugzilla. true... I was wondering if bugzilla could put up a thing like the wiki... fedorabugs just allows triagers to mark dupes, close dead bugs, etc. abadger1999: +1 so, requirement should be 'anyone who has a account and requests it' ? fedorabugs? notting: what's the practical difference between cladone and (cvsextras || fedoraqa) Why not auto-approve fedorabugs for anyone who goes through the hassle of cladone? rdieter: easier to track, i suppose Is that too wide open? rdieter: although, realistically, it's up to fedorabugs-sponsors, or whatever Or auto-approve fedorabugs if cladone and (cvsextras || fedoraqa)? rdieter: well, cvsextras means they have a sponsor... which is... who? nirik: Does fedoraqa run the triage project? How active as fedoraqa been? no idea. Not sure who or what fedoraqa is. ;) How about we approve fedorabugs if they have cvsextras -- fedoraqa sponsors can approve anyone they think is a good triager? is there a large group of people who have accounts but !cla_done? cvsextras || fedoraqa -> automatic fedorabugs approval? (one less manual step) warren: Does fedoraqa require cladone? Why not? warren: +1 My goal is for  triagers to have fedorabugs without having to sign the cla. Why? abadger1999: fedorabugs is not needed to submit patches and do triage work Close bugs as dupes? Doesn't that require fedorabugs? i dont know probably is there a way we can find out what fedorabugs gets? somewhere in bugzilla? or person to ask? perhaps we should gather more info, discuss on list and then figure out things next week? nirik: it gives you alot in bugzilla warren: Because triagers aren't providing more content than a normal submitter to bugzilla.  So why do they need to sign cla? hmm abadger1999: they can reassign bugs to themselves Is that really an impediment to fedoraqa not being successful? I am doubtful. warren: Could be you're right. Someone should talk to mether about it as he's the person who's been approving people for fedorabugs without cladone. who is the contact for fedroraqa? wwoods? nirik: I believe so. nirik: yes Could we decide upon "cvsextras || fedoraqa -> automatic fedorabugs approval? (one less manual step)"  Without deciding whether fedoraqa requires cladone yet? +1, sounds good to me. warren: +1 warren, +1 Or rather, what is different about fedoraqa and fedorabugs? +1 for automatic (Why are they separate?) That's a wwoods question. +1 for auto from what I know now... +1 for auto, exactly what fedoraqa is, needs to be be figured out Does this mean the account system just adds peopel to fedorabugs if they get sponsored to cvsextras? That's what we should do. Someone will have to look at sopwith's code to see if that's currently easy though. I would say so. Might get some more reviewers out of it. ;) yes warren: that would be preferable. OK, we'll see if anyone wants to do that during today's FI meeting. the fedoraqa part figure out later. Sounds good. Anything else people want to discuss? Otherwise we should end the meeting. my question: any chance of merging kde stack before f7t3? Sorta announcement rdieter: depends on the buildsystem. things will be painful and suck without it, I'm afraid. abadger1999: go ahead. rdieter: if we don't get the buildsystem working by test3, we're kind of shot for the merger happening at all for Fedora 7 The PackageDB front end is pretty close to being done.    https://admin.fedoraproject.org/pkgdb/ rdieter: are there still lots of merge reviews outstanding for kde? You can use the interface to enter almost all the owners.list/acl stuff into the database. nirik: lots, part of the problem is than isn't replying to any of them (so far, we're working on that). abadger1999: i checked it out last night looking good abadger1999: looks nice. rdieter: I could help out with some if you like... would like to see KDE happy. ;) nirik: thanks, please do. ok, I'm done, gotta go too. Thanks. We'll need to rewrite the things that draw from ownerss.list to use the packagedb instead. notting do you have time to do some of that? rdieter: well, if you can get the entire stack dep clean from the rest of current-core before then... abadger1999: um, i dunno. -- MARK -- Meeting End
 * jeremy is here
 * daMaestro here
 * spot is barely awake
 * thl is lurking
 * cweyl takes his place in the rabble seats
 * c4chris is here now
 * dgilmore votes +1 on same condition as notting
 * sigh*
 * rdieter thinks f13 is making a lot of sense, bandaid ripping may be the best option.
 * rdieter think warren is very proficient is his use of the cluestick.
 * cweyl is starting to be reminded of the %{buildroot} vs $RPM_BUILD_ROOT messiness
 * nirik agrees with jeremy
 * warren believes fedoraqa is not successful because it is repeatedly treated as one-time "Bug Day" events rather than a consistent project with consistent leadership, roadmaps, organization, etc.
 * c4chris needs to bg real soon
 * bpepple will end the meeting in 60
 * bpepple will end the meeting in 30
 * bpepple will end the meeting in 15