Extras/SteeringCommittee/Meeting-20061228

= 2006 December 28 FESCo Meeting =

Note: due to the holiday season is was expected that probably only small number of people could participate. FESCo nevertheless choose to run a small and meeting without actually voting on anything.

Present

 * thl
 * bpepple
 * tibbs
 * dgilmore

Absent

 * jwb
 * jeremy
 * scop
 * warren
 * ch4chris
 * abadger1999
 * spot
 * awjb
 * rdieter

Minimal approve messages
Background: Some packages ( krename: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220210 and pyfribidi: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219071 ) were not branched by our human cvs guards because it was unclear if a full review had beed done for them -- at branch request time there was only a small note "APPROVED" in a comment of thereview bugs without details what things had been checked


 * dgilmore: the reason i refused to branch those two packages was that the review just said i approve this; [...] i had no way to know if any checking or anything was done
 * tibbs: I agree that minimal reviews are bad (although they used to be more common) but I'm not sure the two in question were minimal.
 * thl: I'm wondering if we should add a rule like "the review has to at least mention 8 points he checked when approving a package"

The decision went towards a proposed new rule: "the reviewer has to at least mention that he checked the license, if the sources match upstream and 5 other points he checked when approving a package". Dgilmore will post to f-e-l about this whole thing in more detail and start a public discussion before FESCo discusses this further.

Site note: the packages will probably get branched now, but the general problem remains.

How to get something realized in Extras
thl wrote http://www.fedoraproject.org/wiki/Extras/Schedule/HowToGetSomethingRealized, tibbs improved it slightly -- FESCO members that were around liked it, Will get posted to f-e-l for further comments.

free discussion around Extras

 * there are still so many broken deps -> seems the ones that are left need real work.
 * XulChris: "is a dist tag of fc#.foo okay for 3rd party repos?" Some disussions around this, the general consensus was "yes". XulChris will probably make a wiki page for guidelines (no rules -- people don't have to follow it, but they can if they want) on setting up a 3rd party repo and what dist-tag to use.

Log
00:01 <        thl> | FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, jeremy, jwb, rdieter, spot, scop, thl, tibbs, warren 00:01           --- | thl has changed the topic to: FESCo meeting -- Meeting rules at [WWW]  http://www.fedoraproject.org/wiki/Extras/Schedule MeetingGuidelines -- Init process 00:01 <        thl> | Hi everybody; who's around? 00:01 <   dgilmore> | pong 00:01 <@     tibbs> | I'm here. 00:01             * | bpepple is here. 00:01             * | thl seems to be one minute late 00:01           --> | |DrJef| (spacious... he's so) [n=jefrey@fedora/Jef]  has joined #fedora-extras 00:01             * | nirik is in the rabble stands. 00:02 <        thl> | hmmmm, that makes four FESCo members... 00:02 <   dgilmore> | thl: there is probably a few on holiday 00:02 <        thl> | do we want to run a normal meeting with only four? I don't think that makes to much sense 00:02 <        thl> | dgilmore, yeah, probably 00:02             * | thl was not at work today, too 00:02 <    bpepple> | thl: probably not. 00:03 <   dgilmore> | thl: that doesnt make much sense  we cant decide on anything 00:03 <   mmcgrath> | pong 00:03 <        thl> | dgilmore, shall we discuss the branching issue roughly? 00:03             * | thl tries to find it on the schedule 00:04 <   dgilmore> | thl: sure 00:04 <@     tibbs> | Yes, please. 00:04             * | lmacken will be around 00:04 <    bpepple> | dgilmore: Is that about the minimal reviews? 00:04 <   dgilmore> | the reason i refused to branch those two packages was that the review just said i approve this 00:04 <   dgilmore> | bpepple: yeah 00:04             * | bpepple agrees with dgilmore on this. 00:04 <        thl> | we talked about that ages ago 00:05 <   dgilmore> | i had no way to know if any checking or oanything was done 00:05 <@     tibbs> | I agree that minimal reviews are bad (although they used to be more common) but I'm not sure the two in question were minimal. 00:05 <        thl> | I'm wondering if we should add a rule like "the review has to at least mention 8 points he checked when approving a pacakge" 00:05 <@     tibbs> | Does anyone have links handy? 00:05 <      nirik> | he since added ot those reviews with a bunch of checklist items. 00:05 <    bpepple> | tibbs: I disagree. He didn't mention anything that he checked in it. 00:05             * | dgilmore would like that at least there is written in the approval post,  that 1) i built this in mock, 2) the spec meets the guidelines  and 3) the md5sum matches upstream 00:05 <@      tibbs> | Ah: 00:06 <@      tibbs> | krename: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220210 00:06 <@      tibbs> | pyfribidi: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219071 00:07            --- | thl has changed the topic to: FESCo meeting -- minimal approve messages 00:07 <@      tibbs> | Hmm, no krename isn't one of them. 00:07 <@      tibbs> | No, neither of those is correct.  Crap, which are the problem reviews:? 00:08 <         thl> | http://fedoraproject.org/wiki/Extras/CVSSyncNeeded?action=recall&rev=2462 00:08 <         thl> | tibbs, those were it afaics 00:08 <     bpepple> | tibbs: He only put in the details after dgilmore informed him he wouldn't branch. His initial review consisted of this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219071#c2 00:08 <        thl> | welÃ¶l, those reviews are not the only ones where it happend 00:08 <@     tibbs> | There has never been a requirement that reviewers actually post the checklist. 00:09 <        thl> | so I still suggest something like "the review has to at least mention that it was build in mock, the sources match upstream and 5 other points he checked when approving a pacakge" 00:10 <   dgilmore> | thl: +1 00:10 <    bpepple> | thl: That sounds fine with me. 00:10 <        thl> | tibbs, no, not yet, but I feel uncompfortable if people just write "approved" -- especially if they are new in the game (which is not the case here) 00:10 <@     tibbs> | It was also never a requirement that reviewed packages were built in mock. 00:10 <    bpepple> | thl: Maybe they should also have to verify the package license in the review also. 00:10 <   dgilmore> | long time reviews need to set an example for new reviewers 00:10 <    bpepple> | dgilmore: +1 00:11 <@     tibbs> | mock takes either significant infrastructure or significant time (or both) to run. 00:11           --> | schlobinux1 (Xavier Bachelot) [n=xavierb@...]  has joined #fedora-extras 00:11 <@     tibbs> | We want to encourage reviews, not put up a pile of beauracracy making it more difficult to find reviewers. 00:11 <    bpepple> | tibbs: How else can a new reviewer easily check that all the BR are there? 00:11 <   dgilmore> | tibbs: yes  but one of the review guidelines is that it must build in mock on at least one arch 00:11 <        thl> | next round: "the reviewer has to at least mention that he checked the license, the sources match upstream and 5 other points he checked when approving a pacakge" 00:12 <    bpepple> | thl: +1 00:12 <   dgilmore> | thl: that is fine also 00:12 <   dgilmore> | +1 00:12 <@     tibbs> | dgilmore: The only mention of mock in the review guidelines is a "should". 00:12 <    bpepple> | tibbs: maybe the guideline need to be modified. 00:12 <@     tibbs> | The requirement is that it compile and build into binary rpms on at least one supported architecture. 00:12 <@     tibbs> | Well, cart before the horse, then. 00:12           <-- | schlobinux_ has quit (Read error: 110 (Connection timed out)) 00:13 <        thl> | tibbs, +1, I don't consider the mock stuff to important 00:13 <        thl> | it was more important in the fedora.us days when there was a semi-automatical buildsys 00:13 <@     tibbs> | Plain reviews were the norm before I started doing the long checklists. 00:13             * | mmcgrath notes it'll build in mock before it gets to our end users anyway 00:13 <@     tibbs> | And there were complaints at the time that I was posting too much. 00:13 <        thl> | mmcgrath, +1 00:14 <    bpepple> | Does Toshio python qa tool still work? 00:14 <   dgilmore> | tibbs: that probably should be a must 00:14 <        thl> | tibbs, well, in my memory most reviews had at least some things listed that the reviewer checked; only a small number had just the "approved" message 00:15 <        thl> | but tha's history now in any case 00:15             * | nirik always used a checklist based on the 'how to review a package' page. 00:15 <    |DrJef|> | bah... all this back and forth in my review over a trivial helper script that I want to place in a %docs section 00:15 <        thl> | tibbs, so what do you suggest? Leave everything as it is? 00:15 <   XulChris> | why dont we write a shell script that goes through the review checklist and the reviewer can mark yes no or n/a on each item then the shell script automatically generates the review text 00:16 <        thl> | XulChris, no, I'd leave some freedom for the reviewers how they do there work 00:16 <    bpepple> | XulChris: That's what Toshio's tool did, though it was a gtk+ gui. 00:16 <        thl> | we can of course write one, but we should not force it on people 00:16 <    |DrJef|> | XulChris, i like that... spot had a checklist cheatsheet in his wikipages 00:16 <        thl> | XulChris, and what bpepple said ;) 00:16 <         thl> | |DrJef|, there are multiple ones in the wiki iirc 00:16 <@      tibbs> | Here's a nice one: 00:16 <@      tibbs> | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167254 00:16 <    dgilmore> | All i really want is some evience that a review was done 00:17 <     |DrJef|> | thl, spot's is oldest :-> 00:17 <         thl> | |DrJef|, a lot of people maintain there own variant 00:17 <     bpepple> | Ah, there's the name: qa-assistant. 00:17 <@      tibbs> | I don't object to asking people to post a list of what they checked. 00:17 <@      tibbs> | I just think this whole issue is rather unpleasant. 00:18 <         thl> | tibbs, so in other words you'd like to stick to the current behaviour? 00:18 <@      tibbs> | No slight against dgilmore intended, but I don't recall who appointed him the gatekeeper of what a good review is. 00:19 <    |DrJef|> | tibbs, i think process transparency requires a checklisting... including the should items 00:19 <   dgilmore> | tibbs: any of the branches can refuse to branch if they feel the review in not appropriate 00:19 <        thl> | tibbs, those that branch cvs are requires to look at the review 00:19 <    |DrJef|> | tibbs, an explicit checklist continues to re-affirm best practices  to new contributors 00:19 <   XulChris> | dgilmore: thing is everyone will be able to do their own branches soon 00:20 <    |DrJef|> | tibbs, and if saged contributors aren't doing it....new people dont respect it 00:20 <@      tibbs> | One version of the checklist I use is even online. 00:20 <   dgilmore> | XulChris: yes so we need to have an automated way to ensure things are ok then 00:20 <    |DrJef|> | tibbs, whatsmore.. as policy shifts... the checklisting helps reviewers tell other reviewers about policy changes they nissed 00:20           <-- | k0k has quit (Read error: 104 (Connection reset by peer)) 00:20 <       ecik> | my review template is at wiki as well 00:20 <@     tibbs> | But if someone wants " a checklisting... including the should items" then I don't think that even my reviews qualify. 00:20 <   dgilmore> | XulChris: we can write a script that parses the review  for certain things 00:21 <    |DrJef|> | tibbs, should include... not must 00:21 <        thl> | tibbs, that why I proposed "the reviewer has to at least mention that he checked the license, the sources match upstream and 5 other points he checked when approving a pacakge" 00:21 <    |DrJef|> | tibbs, knowing what shoulds have been done.. help other people manage their time..so they dont redo shoulds 00:21 <        thl> | it stays up to the review what 5 things he checks 00:22 <        thl> | that afaics still should be quite easy to satisfy 00:22 <    bpepple> | thl: agreed. 00:22 <   dgilmore> | thl: that works   and we can sript the checking of that for branching 00:22 <   dgilmore> | s/sript/script/ 00:22             * | nirik wonders how checking that can be scripted... since bugzilla text is free form. 00:23 <        thl> | well, let's stop here 00:23 <        thl> | and get back to it next week 00:23 <        thl> | does anybody want to bring this topic to the list for discussions? 00:24 <   dgilmore> | thl: i will as i started it 00:24 <         thl> | not all at once please ;-) 00:24 <         thl> | dgilmore, thx 00:24            --> | rafalzaq (RafaÅ) [n=rafalzaq@...]  has joined #fedora-extras 00:24            --- | thl has changed the topic to: FESCo meeting -- How to get something realized in Extras 00:24 <         thl> | tibbs, thx for fixing/enhancing the page 00:24 <    dgilmore> | thl: i liked what you posted 00:24 <         thl> | bpepple, what do you think of it? 00:24 <         thl> | and tibbs ? 00:25 <     bpepple> | thl: I liked it. 00:25 <@      tibbs> | Sorry, phone. 00:25 <         thl> | dgilmore, bpepple, should there be more/anything else on the page? 00:25 <         thl> | tibbs, np 00:25 <         thl> | btw, we are talking about http://www.fedoraproject.org/wiki/Extras/Schedule/HowToGetSomethingRealized 00:26 <         thl> | I'm wondering if I should just post about it to the list 00:26 <        thl> | so people can comment 00:26 <   dgilmore> | thl: not that i can think of right now. But it is good to make everyone aware they dont need to be in FESCo or some other committie to get things done 00:26 <@     tibbs> | It makes sense to me. I get tired of people saying "fesco should do something" and then just leaving it for us to figure out what (if anything) to do. 00:26 <        thl> | dgilmore, that eactly why I wrote it 00:26 <     bpepple> | off the top of my head I can't think of anything. I'm glad you mentioned that part about what FESCo isn't. 00:26 <        thl> | so shall I take it to the list? 00:27 <   dgilmore> | thl: do 00:27 <     bpepple> | thl: yes. 00:27 <@     tibbs> | Yes, I think so. 00:27           --> | Sonar_Guy (Scott Glaser) [n=sglaser@fedora/sonarguy]  has joined #fedora-extras 00:27 <        thl> | k, will do 00:27            --- | thl has changed the topic to: FESCo meeting -- free discussion around Extras 00:27 <        thl> | so, anything else? 00:27 <        thl> | there are still so many broken deps 00:27 <   XulChris> | i have a question about last weeks meeting 00:28 <@     tibbs> | I have tried to rebuild essentially every busted dep at this point. 00:28 <   XulChris> | is a dist tag of fc#.foo okay for 3rd party repos? 00:28 <@     tibbs> | The ones that are left need real work. 00:28 <        thl> | tibbs, okay, many thx 00:28 <        thl> | XulChris, good question... 00:28 <        thl> | XulChris, you maybe should ask spot and/or the packaging committee 00:29 <@     tibbs> | Should we try to say what 3rd party repos should do? 00:29 <        thl> | XulChris, I tend to think "yes" 00:29 <    bpepple> | XulChris: I believe the tag should match the distro it is for. Spot would probably be the one to ask, since he felt strongly about it. 00:29 <        thl> | tibbs, no, of course not, but ge can guide 00:29 <@     tibbs> | I guess if they're asking our opinion it's OK. 00:29 <   XulChris> | i think we should make a wiki page for guidelines on setting up a 3rd party repo 00:29 <    bpepple> | XulChris: Probably not a bad idea. 00:30 <@     tibbs> | If by "we" you mean "I"  then I'm all for it! 00:30 <   XulChris> | if by "I" you mean "you"... ;-) 00:31 <   XulChris> | im not sure i know enough about setting up a 3rd party repo to actually write a guidelines page 00:31 <@      tibbs> | But seriously, I don't suppose it could hurt.  I'm just wary of the potential for flamewars. 00:31 <     |DrJef|> | XulChris, you have to be very very clear that such a page is meant as a best effort to help 3rd parties synergize with fedora packaging policy.. and its not meant as a coersive set of rules 00:31            <-- | Sonar_Guy has quit (Remote closed the connection) 00:31 <@      tibbs> | Damn, I had a nice review of libsieve written up and firefox crashed. 00:31 <         thl> | tibbs, you did not get asbestos underwear for christmas? 00:31 <    XulChris> | |DrJef|: yes, ultimately its just a set a guidelines 00:32 <     |DrJef|> | XulChris, guidelines which will be in flux 00:32 <    XulChris> | I can start a draft but ill probably need some help 00:32 <    |DrJef|> | XulChris, if the language on the page isn't overly squishy, people will misread it as a written-in-stone specification for compatibility 00:33 <   XulChris> | well its a wiki so people can fix up any bad language 00:33 <   dgilmore> | i think its perfectly fine for 3rd party repos to use .fcx  if they choose to 00:33 <     |DrJef|> | XulChris, the best way to approach it is to think about people who run in house distros 00:34 <    |DrJef|> | XulChris, instead of thinking.. generally public repos 00:34 <    |DrJef|> | XulChris, err inhouse repos 00:34 <@     tibbs> | Of course, such a page would have to say "don't replace or upgrade existing Fedora packages", which gets you into a heap of flames already. 00:34 <   XulChris> | dgilmore: i was asking about fcx.foo like fc6.lvn 00:34 <   dgilmore> | |DrJef|: i have inhouse repos and use .el4 00:34 <   dgilmore> | XulChris: they are free to use what they want 00:34 <   XulChris> | tibbs: no we would just recommend to not do so, list reasons why, and also list exceptions 00:35 <   XulChris> | dgilmore: yes they are free, but they *should* be using fcx 00:35 <    |DrJef|> | dgilmore, im just suggesting that as XulChris writes this... he thinks of the audience as people with inhouse repos.. instead of the more obvious repo targets out in the wild.... 00:35 <   dgilmore> | XulChris: we have no say on what they do ro dont do  or what they should or should not be doing 00:35 <   XulChris> | dgilmore: we definately have a say on what is good practice 00:36 <   dgilmore> | we can say whats good practice for Fedora 00:36 <   XulChris> | and we can also say what is good practice for repos that use fedora 00:36 <   dgilmore> | wheather they follow that it up t othem 00:36 <   XulChris> | ofcourse 00:36 <   XulChris> | we arent mandating anything 00:36 <   dgilmore> | XulChris: we have zero influence on that 00:36 <        thl> | XulChris, please also mention that users should set the vendor and/or packager tags 00:37 <   dgilmore> | XulChris: all we can do is set guideelines for us and hope that third party repos follow them 00:37 <   XulChris> | dgilmore: thats all im asking we do 00:37 <    dgilmore> | XulChris: livna in my opinion should use .fcx  as a disttag 00:38 <   dgilmore> | but thats just my opinion 00:38 <   XulChris> | ya thl just mentioned livna's dist tag will be fixed 00:38 <        thl> | well, the disttag is not that easy 00:38 <   XulChris> | and dribbles dist tag also because dribble will do what livna does 00:38 <       ecik> | but if it uses .lvnx it is easier to check what repo package is from 00:38 <        thl> | as fcx is lower then lvn 00:39 <   XulChris> | thl: ya unfortunately for livna it means a rebuild, might be easier to only do it for fc7 00:39 <        thl> | XulChris, I'll see what livna will  do in the long term 00:39 <        thl> | XulChris, yeah, probably 00:39 <        thl> | anyway, anyting else regarding Extras we should discuss? 00:39 <        thl> | otherwise I'll close the meeting for today 00:40 <    bpepple> | of course shouldn't our dist tags be f7, since Core is eventually gonna dissappear? 00:40 <        thl> | bpepple, hehe 00:40 <        thl> | bpepple, that probably a decision for the PC (sorry, once again I try to move work to the PC...) 00:40 <   XulChris> | fu7 (fedora universe 7) ;-) 00:40 <         thl> | Fedora Nexus 00:41 <     bpepple> | Oh no, another naming session. ;) 00:41             * | thl will end the meeting in 60 00:41             * | thl will end the meeting in 30 00:42             * | thl will end the meeting in 13 00:42           <-- | Belegdol has quit ("Leaving") 00:42 <        thl> | -- MARK -- Meeting End