Hello all, Sebastien Bacher [2012-06-04 10:33 +0200]: > Ideally builds would be tested on a q build system before upload, > while that's not hard work it's also not a "small amount of extra > work" if you are running still the stable serie (it's easy enough to > set a pbuilder or so but it's still work and I'm not sure we should > force people who contribute a SRU fix to go through that)
I would not call it mandatory for patch/SRU contributors to fix unrelated FTBFS issues in the development release, only if the SRUed patch itself causes the breakage. One of the main reasons for the "devel first" requirement is to prevent people from forgetting to introduce the fix into it. For that part, I think it is sufficient to get the fix landed in the upstream trunk, and credibly point out that there will be another upstream release with that fix until the current devel release gets frozen. At this early time of Quantal, and a package like Unity this is fairly obviously true. I fully trust members of the SRU team to judge about this on a particular case, taking the urgency of the fix for stable into account, and require (or not) a fix in the devel release first. The other main reason for the "devel first" requirement is to get changes tested by a larger number of people before it gets deployed to millions of users. This gradually becomes more true and effective the later in the development cycle we are. Right now it doesn't show much benfit, though: there are still very few users of Quantal (we haven't had a single milestone release yet), and a lot of users are testing SRUs for 12.04 LTS. > 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..) Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
