19:30:15 <nirik> #startmeeting FESCO (2010-08-10)
19:30:15 <zodbot> Meeting started Tue Aug 10 19:30:15 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:15 <nirik> #meetingname fesco
19:30:15 <zodbot> The meeting name has been set to 'fesco'
19:30:15 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:15 <nirik> #topic init process
19:30:15 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:43 <nirik> #info mjg59 said he would be unable to attend today.
19:30:53 <nirik> #info mclasen said he would be ~15min late.
19:31:18 <pjones> I'm here.
19:32:52 * SMParrish here
19:33:01 * nirik wonders if we will have quorum today. ;)
19:33:14 <gholms|work> Is this really the best time for this meeting?
19:33:29 <nirik> gholms|work: it was last we asked everyone.
19:33:52 <pjones> ish.
19:34:37 <nirik> yeah, there was no ideal time, but this was the least bad.
19:35:08 <ajax> hey
19:35:17 <pjones> why hello ajax, how are you?
19:35:49 <notting> here now. sorry about that.
19:36:14 <nirik> ok, I guess thats 5... hopefully a short meeting today. ;)
19:36:27 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:36:27 <nirik> .fesco 351
19:36:29 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:36:44 <nirik> still waiting on bodhi changes to land and autoqa to land.
19:37:09 <nirik> there was some confusion about our policy and f14 builds to fix broken python/boost deps.
19:37:46 <nirik> people were hoping to push those to stable directly.
19:38:27 <nirik> I'm not sure when the next bodhi update lands... has some more things we want in it...
19:38:31 <nirik> lmacken: any news?
19:38:43 <jsmith> As I understand, it's after the RC is accepted
19:38:46 * nirik knows it was deployed in staging.
19:38:50 <ajax> was the motivation for wanting to push those to stable just promptness?
19:39:18 <nirik> ajax: I guess the thought was that the new package without broken deps would at least be installable.
19:39:31 <nirik> and perhaps to avoid more nag mail about broken deps?
19:39:32 <notting> nirik: then it should be easy to test)
19:39:41 <nirik> yeah.
19:40:05 <nirik> anyhow, hopefully bodhi changes will land and all we will have left is autoqa.
19:40:11 <nirik> anything else on this from anyone?
19:40:22 <ajax> not from me
19:40:33 <nirik> ok, moving on to the related ticket then...
19:40:35 <nirik> #topic #382 Implementing Stable Release Vision
19:40:36 <nirik> .fesco 382
19:40:37 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:40:54 <nirik> so, anyone made any headway on their tasks related to this?
19:41:17 <notting> not i, alas.
19:41:35 <ajax> i haven't had any tasks related to this, partly because i haven't volunteered for any
19:41:40 <pjones> I think he's the only person with an assigned task who's *here*
19:41:41 <SMParrish> I have nothing new
19:41:41 <nirik> discussion has continued on the board list about the "only fix bugs and security issues" wording
19:41:42 <ajax> is there something that needs attention?
19:41:47 <pjones> oh, also SMParrish
19:42:03 <nirik> well, it would be nice to move this all forward somehow.
19:42:08 <pjones> (huh, so I parse it differently capitalized vs lower case)
19:42:46 <nirik> the assignments are in the ticket.
19:43:12 <nirik> I have updated https://fedoraproject.org/wiki/Updates_Lessons a bit more.
19:43:58 <nirik> I wonder if we shouldn't look at having a topic/ticket on new updates breakages when they happen... possibly QA more than us, but look at the breakage and try and see how we could prevent it.
19:44:24 <nirik> welcome mclasen
19:44:55 <ajax> nirik: trac queue maybe?
19:44:58 <pjones> nirik: yeah
19:45:09 * mclasen apologizes for being late
19:45:23 <nirik> ajax: yeah, qa already has one... or should we look at the issues in fesco track.
19:45:33 <nirik> there was a new one this last week. ;) lvm2 fun.
19:45:37 <ajax> nirik: what's the qa one?
19:45:57 * nirik looks
19:46:05 <notting> nirik: i thought the lvm2 one only went to -testing
19:46:20 <nirik> notting: yeah, it was testing only.
19:46:34 <nirik> https://fedorahosted.org/fedora-qa/report
19:46:45 <mclasen> somehow PK was being implicated for using skip-broken, I think ?
19:47:36 <nirik> mclasen: yeah, it uses skip-broken by default? the problem was part of the update applies if you skip broken... some of the subpackages, just not the main package.
19:47:42 <notting> mclasen: well, using --skip-broken can cause odd things to happen depending on the sort of dep failures.
19:48:09 <mclasen> right, I'm not exactly sure what PK does by default here
19:48:13 <mclasen> I can investigate
19:48:22 <nirik> anyhow, yes, it was testing only (it was requested for stable, but I edited it to testing before it pushed out)
19:48:58 <pjones> well, --s-b is certainly the wrong thing to do - if you're in that situation, using --s-b might be a tool you can use to work out of it, but that's not what PK is going to be doing.
19:49:22 * nirik doesn't know that it does... I was just told that it does by default. Could be inaccurate info.
19:49:49 <mclasen> I will find out
19:49:55 <nirik> can anyone think of how we could move this ticket forward? Or should we keep working on the tasks and trying?
19:50:08 <nirik> or perhaps we could add another assigniee to each of the tasks to help ?
19:50:56 <ajax> sign me up for whatever, i'm (finally) at a break with my other responsibilities
19:51:15 <nirik> ok, right now we have:
19:51:30 <notting> i'll take another volunteer for the 'writing docs' part, sure
19:51:48 <nirik> notting to work on Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs.
19:51:48 <nirik> SMParrish to work on Fedora 14: metrics on how many updates each branch gets including rawhide?
19:51:48 <nirik> nirik to work on Fedora 14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.
19:51:48 <nirik> kylem to work on Fedora 14: Have an updates-features optional repository.
19:51:50 <nirik> mjg59 to work on Fedora 14: Document a exception process. Some packages will need to provide updates for security reasons or working with external sources, etc.
19:52:49 <ajax> i'll start on nottings and then start working through the others
19:52:57 <nirik> that would be lovely. ;)
19:53:51 <nirik> #action ajax will help with docs and move on to other tasks
19:54:10 <nirik> #action nirik will talk with QA about tracking and documenting updates issues.
19:54:19 <nirik> anything further? or shall we move along now?
19:55:01 <nirik> ok, on to new business:
19:55:05 <nirik> #topic #448 Disallow packages whose primary owner is group.
19:55:05 <nirik> fesco 448
19:55:24 <nirik> .fesco 448
19:55:26 <zodbot> nirik: #448 (Disallow packages whose primary owner is group.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/448
19:55:39 <nirik> basically this is about our old friends... merge reviews.
19:55:52 <notting> so, i think the original request is right out. but we should probably try and find another way to address his concerns
19:55:53 <nirik> The reporter wants a single person to bug about finishing them.
19:56:00 <ajax> life sure is hard.
19:56:04 <nirik> notting: yeah.
19:56:26 <nirik> I made some suggestions on merge reviews a while back on the devel list.
19:56:30 <pjones> I think this is pretty ill-considered.
19:57:09 <nirik> I don't think we should force packages to have a single owner, nor do I think doing so would help move merge reviews forward anymore.
19:57:15 <pjones> right.
19:57:19 <mclasen> we should not let merge reviews become a fetish; or let them create bad blood between reviewers and maintainers for another 3 years...
19:57:19 <SMParrish> I agree
19:57:34 <pjones> all evidence seems to indicate packages with single owners have just as many merge review problems.
19:57:38 <pjones> mclasen: no kidding.
19:57:39 <nirik> http://lists.fedoraproject.org/pipermail/devel/2010-July/138566.html
19:58:10 <nirik> there's 225 of them left
19:58:21 <notting> not sure there's really more to do other than to state as policy 'if someone is doing a merge review of your package, please interact with them'. should be common sense.
19:58:32 <nirik> #info 225 merge reviews left currently.
19:58:36 <pjones> I think the biggest reason people don't fix up merge review problems is that they often appear to be a giant waste of time.
19:58:46 <ajax> i guess i'm wondering how many of those that are left are actually non-trivial
19:58:54 <pjones> (though in reality those usually turn out to be fairly small wastes of time...)
19:59:00 <pjones> ajax: indeed.
19:59:01 <ajax> as opposed to how many could just be drive-by fixed by a provenpackager
19:59:05 <nirik> http://fedoraproject.org/PackageReviewStatus/MERGE.html
19:59:22 <nirik> we could allow provenpackagers to fix merge review issues...
19:59:33 <ajax> we allow provenpackagerts to fix _any_ issues
19:59:37 <ajax> i don't see why this is special ;)
19:59:38 <notting> nirik: fine with that too
19:59:40 <nirik> but that might result in provenpackagers "fixing" something about a package they don't know and that breaks it. ;)
19:59:40 <pjones> ajax: actually, I wonder how many of them are because rpmlint (wrongly) issues a warning about buildroot
20:00:08 <pjones> nirik: I think part of the point of provenpackagers is that they should also know when not to touch it...
20:00:18 <nirik> right.
20:00:57 <ajax> back when we used to have a codevelopment policy...
20:01:12 <notting> i suspect most provepackagers would like at least some level of 'ack' from the maintainer. i suppose you could take the lack of a nack as good enough, though
20:01:31 <ajax> i'm a bit more cavalier than that
20:01:34 <nirik> proposal: allow/encourage provenpackagers to commit (to rawhide) fixes for merge reviews. Keep merge reviews open and try and get them all done someday
20:02:00 <pjones> +1
20:02:03 <ajax> +1
20:02:06 <mclasen> I think a lot of merge reviews could be helped over the hump by attaching a patch, and asking 'is this ok to commit' ?
20:02:06 <drago01> "allow" ?
20:02:13 <notting> nirik: with the caveat that the pp in question shouldn't be the reviewer, +1
20:02:15 <pjones> drago01: "encourage"
20:02:40 <drago01> pjones: thats better ... but we voting on allowing something that is already allowed is ...
20:02:58 <nirik> notting: I guess thats ok too...
20:03:02 <pjones> drago01: it's not a problem, don't worry about it ;)
20:03:16 * drago01 shuts up ;)
20:03:26 <SMParrish> +1
20:03:35 <nirik> so do we want to just leave it at that? or be more formal about it? ie, submit a patch, wait a week for ack/nack, etc?
20:03:52 <pjones> nirik: they're provenpackagers.  they can fix things.  it's okay.
20:04:14 <nirik> ok, so:
20:04:51 <nirik> agreed: encourage provenpackagers to commit to rawhide fixes for merge reviews. said pp's should not be the reviewer. Someday before the end of time we will finish all the merge reviews
20:04:56 <nirik> (does that look ok to everyone)
20:05:06 <pjones> sure.
20:05:09 <ajax> perfect
20:05:12 <SMParrish> fine
20:05:22 <gholms|work> What is the recommended course of action for non-provenpackagers who are trying to do merge reviews?
20:05:30 <ajax> i'll even start doing more of them (by which i mean, any)
20:05:33 <mclasen> the thing that makes obsessing about merge reviews so sad is that all the other packages need just the same amount of cleanup love to stay in sync with guidelines...
20:05:50 <notting> gholms|work: find a provenpackager to commit if you don't get a response. we have enough of them...
20:06:07 <ajax> gholms|work: patches on the bug are a good start (although i assume many of them have one)
20:06:26 <nirik> #agreed: encourage provenpackagers to commit to rawhide fixes for merge reviews. said pp's should not be the reviewer. Someday before the end of time we will finish all the merge reviews
20:06:38 <pjones> gholms|work: add a patch to the bug, poke a provenpackager if that doesn't move it forward.
20:07:17 <nirik> #topic FES ticket roundup
20:07:26 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
20:07:47 <nirik> mmcgrath: anything to report of late? are we stagnating here? need more people? more tickets?
20:07:50 <mmcgrath> we're still sitting big on the sub tasks.  I need to do another ping round up.
20:08:03 <mmcgrath> we're pretty stagnated, more people.  I haven't been particularly good about rounding up the troups.
20:08:08 <mmcgrath> I'll send an email out this afternoon.
20:08:31 <mmcgrath> I also haven't put in my time yet this week
20:08:42 <mmcgrath> sorry for the lack of updates beyond that.
20:08:44 * nirik can probibly come up with some more tickets.
20:09:29 <nirik> f14 currently has a bunch of broken deps. ;)
20:09:48 <mmcgrath> I do have a post-alpha task to take on soon wrt clean upgrade paths.
20:10:20 <nirik> cool. I'd like to try and get things moving on it, we were doing good for a while... it's hard to maintain energy sometimes tho
20:10:37 <mmcgrath> yeah
20:10:56 <nirik> ok, thanks mmcgrath.
20:11:04 <nirik> #topic Open Floor
20:11:10 <nirik> anyone have items for open floor?
20:11:27 <notting> 'fix your alpha bugs'
20:11:54 * nirik nods.
20:12:41 <nirik> ajax: if you have time, any news on https://fedorahosted.org/fesco/ticket/370 ?
20:12:45 <nirik> .fesco 370
20:12:46 <zodbot> nirik: #370 (allow bundling libiberty) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/370
20:13:05 <ajax> i finally got a scan that actually finds all the libiberty bundlers
20:13:15 <nirik> cool.
20:13:17 <ajax> need to go through it and see what the version skew is like
20:13:29 <ajax> one sec...
20:14:14 <ajax> http://fpaste.org/zdk0/ as of F13 is the set of packages that bundle it
20:15:06 <nirik> cool. Should we discuss that ticket now then?
20:15:15 <ajax> i still feel the whole thing is overblown, that if it were in a source dir called common/ no one would notice the copypasta
20:15:22 <ajax> but hey, why not obsess over details
20:16:12 * nirik is ok with discussing it now, or waiting until next week...
20:16:18 <ajax> but yeah, i want to go through those to see if there's any appreciable version skew among them
20:16:37 <ajax> and then i guess we decide that it's okay for toolchain and not anything else, or, whatever.
20:16:51 <nirik> yeah, ok.
20:17:02 <ajax> i'll have that by next week
20:17:03 <nirik> update the ticket with the info and add 'meeting' keyword and we can deal with it next week.
20:17:09 <ajax> k
20:17:34 <nirik> anyone have anything else?
20:18:01 * nirik will close out the meeting in a minute then...
20:18:09 <pjones> do eet.
20:18:31 <nirik> #endmeeting