Hiya, [ fixing Brian's email address — how is it not [email protected]? :-) ]
On Tue, Jun 05, 2012 at 05:50:12PM +0200, Martin Pitt wrote: > Hello all, > […] > > The other option there would have been to block the LTS SRU on > > getting those issues resolved and we wanted to see some of the bugs > > fixed and sooner that later so I'm unsure delaying the SRU was the > > right way either... > > I agree, we should not delay important/urgent bug fixes on that. I > would not accept a fix which is _only_ a patch in a stable-proposed > package, as that is too sloppy from the uploader and shifts the > responsibility for caring about the patch upstreaming from the author > to the SRU team or generally the Ubuntu developers. But in that > particular Unity case that does not apply. > > So in summary: I think common sense and discretion of the SRU team > reviewers are in order here, as in many cases of the SRU process. > (Things like that make it so hard to write a firm policy and automate > much of it..) Right. So the point of my mail is that I don't like to see FTBFSing uploads to the development release which are the result of this "must be fixed in the development release" policy. I think everyone agrees that it's important to get fixes out to users of the stable release, and I'd actually prefer it if the development release remains unfixed for a bit if the patch isn't going to work there yet, *as long as there is a plan to make it so*. I think the SRU policy actually can be modified to make this the case; change point 1 to indicate that, when the fix isn't available yet (this means built and working), there should be a clear plan as to how it will shortly become available. In the Unity case this could have said that the patch is in trunk and is blocked on some gcc-4.7 work which is ongoing. SRU team members can then judge whether they accept the plan. Perhaps all such bugs should be milestoned or otherwise tracked too so the fix isn't lost. Cheers, -- Iain Lane [ [email protected] ] Debian Developer [ [email protected] ] Ubuntu Developer [ [email protected] ] PhD student [ [email protected] ]
signature.asc
Description: Digital signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
