[13:03] <cjwatson> hopefully-final 10.04.2 images building now
[13:18] <cjwatson> whoops, Ubuntu alternate failed due to my own stupidity; I'll have to go back and rebuild that later
[13:43] <pitti> skaet: hm, what do we do with bugs like bug 668615? they keep reappearing in the "desktop team" agenda, but those are universe packages
[13:43] <ubot4> Launchpad bug 668615 in libtorrent-rasterbar (Ubuntu Natty) (and 4 other projects) "Downloads slow, stop, get stuck on "starting up" (affects: 2) (heat: 14)" [High,Fix committed] https://launchpad.net/bugs/668615
[13:43] <pitti> skaet: the bug priority is still correct, as it is an important bug in that package; but it should be handled through normal sponsoring, it's not a thing that any canonical team particularly takes care of
[14:08] <Riddell> seb128:
[14:08] <Riddell> no, sorry
[14:08] <Riddell> skaet: how does freeze work for beta 2?  we have a freeze a week before beta 1 but final freeze is on the same day as beta 2? https://wiki.kubuntu.org/NattyReleaseSchedule
[14:11] <ScottK> pitti: I think that's a problem with the idea that a bug must be assigned to be targetted at a milestone.  You'll get people external to the team assigning stuff and it'll often be wrong.
[14:12] <pitti> ScottK: this one isn't even assigned; I subscribed the sponsors, so it'll get dealt with
[14:12] <ScottK> Right, but wasn't it?
[14:12] <pitti> ah, right, I unassigned it
[15:06] <skaet> pitti, ScottK,   I wasn't sure how to handle 668615 - it looked like it had stalled out with a proposed fix and nothing was happening.    In future, I'll leave them unassigned, but move it to track under MOTU section on the agenda.  That work better?
[15:06] <skaet> Riddell,  good catch.
[15:06] <ScottK> skaet: I think the notion of assignments is more generally problematic.  I don't think it's fair for random devs outside a team to be assigning bugs to a team.
[15:11] <pitti> skaet: as I said I subscribed sponsors; I think that's the right place to queue that
[15:27] <skaet> ScottK,  certainly agree with you that the way assignment is handled is definitely problematic though.   I think that bdmurray's proposal on ubuntu-devel earlier this week is a step in the right direction.   (ie. when bug is nominated for a release, it should not be accepted without an assignment to a person or team)
[15:31] <seb128> skaet, well having non assigned bugs is useful
[15:31] <skaet> seb128, yeah, thats what makes it problematic
[15:32] <seb128> skaet, if you assign everything you need to find someone to assign to and it also leads to have no list of "if you want to help for the release try to fix one of those bugs nobody is actively working on"
[15:32] <ScottK> skaet: That limits the ability to accept bugs to people who can assign bugs to the relevant team.
[15:32] <ScottK> seb128: I agree.
[15:33] <seb128> skaet, often finding someone to assign to bug to leads to assign to busy people who might not have time to fix the issue and block others to help as well since they think the bug is being handled where it's not
[15:33] <seb128> it would be better to be honest about assignment and use those only when the assignee will be able to work on the issue
[15:33] <ScottK> +1
[15:34] <skaet> seb128, ScottK, in general I'm fine with that, but for high and critical bugs someone should be identified to make a decision about them.
[15:34] <ScottK> For unrelated reasons I re-read The Cathedral and the Bazaar yesterday and there's good point in there about resources not being finite in open source projects and wanting to invite more participation.
[15:35] <cjwatson> spuriously assigning to teams isn't quite so bad as spuriously assigning to people, but it generates a lot of mail and it has the problem that if a team is responsible for something then nobody feels individually responsible
[15:35] <ScottK> skaet: I think that having them milestoned and targetted should be sufficient for the purpose of making a decision.
[15:35] <cjwatson> maybe I mean "non-consensually" rather than "spuriously"
[15:36] <ScottK> Probably, but it's a good point.
[15:37] <skaet> ScottK, cjwatson,  so should we create some sort of team place holder for "grab this one if you can help?"  When its blank, and nothing happens on it for over a week, and high/critical - there doesn't seem to be a good answer.
[15:37] <ScottK> skaet: I think that's precisely what unassigned means.
[15:37] <cjwatson> I'm not sure there's necessarily a good answer solely within the bug tracking system - metadata changes don't magic human effort into existence
[15:38] <skaet> ScottK, unassigned also means that no one is looking at it, hence the ambiguity.
[15:38] <ScottK> If nothing happens in $TIME then the release team should start to look into resources/prioritization.
[15:39] <ScottK> skaet: To me unassigned means no one is actively working on fixing it and it's free to take.  I'm not sure what the ambiguity is?
[15:41] <pitti> also, in this case, it's on the sponsoring list now as it has a patch, so it's actually in the right state now IMHO
[15:41] <skaet> ScottK, ambiguity is from release management side - ie, is it going to get fixed?   When the developer proposed the fix, why didn't he claim it?  If its high, milestoned, and release targetted,  it is conceptually a blocker to the release, so needs a plan.
[15:43] <skaet> pitti,  yup, I agree its in the right state now.   Sponsoring queue was what was needed.
[15:47] <ScottK> skaet: Not all developers can fix all bugs.  There are pleanty of times I see things that I know should be fixed for the release, but I'm not going to actually fix it myself.
[15:47] <ScottK> I think we want milestoned/nominated bugs to be what people really think needs fixing.  It shouldn't be limited to what we know we can do.
[15:49] <cjwatson> A lot of nominations are from QA, not from developers
[15:49] <cjwatson> at least that's what I see
[15:49] <skaet> ScottK,  Agree not all developers can fix all bugs, wasn't suggesting that.
[15:49] <cjwatson> so that answered the "why didn't they claim it" rather simply :-)
[15:49] <ScottK> cjwatson: Yes.
[15:51] <skaet> cjwatson, ScottK,  developer I was refering to was the one that proposed the fix,  topdownjimmy
[15:51] <ScottK> skaet: In some cases that's appropriate, but I'm speaking more generally.
[15:51] <skaet> ScottK,  fair 'nuf
[15:57]  * skaet heading over to #ubuntu-meeting for weekly release meeting
[21:22] <jibel> skaet, Hi, are the 10.04.2 images available on cdimages the final ISOs and ready for testing, or will there be respin on Monday ?
[21:36] <skaet> jibel,  looking into it.
[22:19] <skaet> jibel,  didn't see a definitive post from cjwatson on the subject (his last comment in the scrollback was on having to rebuild the alternates for 10.04.2), but in looking in the image list, it looks like they've picked up the language packs we were waiting for, so I think they're good to start testing with.
[22:25] <jibel> skaet, I'll send the invite to sync over the week end and the go for testing on Monday then.
[22:26] <skaet> jibel,  only piece I'm not seeing is the dvd for i386
[22:26] <skaet> but starting testing on Monday makes sense, after cjwatson's had a chance to comment.
[22:56] <cjwatson> jibel,skaet: sorry, knew there was something else I meant to do today.  please go ahead with testing, they should be final
[22:57] <cjwatson> surprised dvds aren't there, I'll check logs in an hour or so
[22:57] <cjwatson> but please send the go for testing in advance of that
[23:06] <skaet> cjwatson, thanks.  do you know if the server images have been spun?