SRUs and the development release

[Martin Pitt]

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)