Thursday, 19 May 2016

Re: SRU never reviewed, why/how do we avoid that next time?

Sebastien Bacher [2016-05-19 10:24 +0200]:
> Libreoffice (to stay on that example) tends to exercice new compiler
> versions/toolchain in challenging ways and it's not uncommon that
> getting it to build on a new serie takes some time. Also it's often the
> case that we aim at landing a new upstream serie on the new distro (same
> for GNOME) and that we prefer to get that going rather than spending
> time trying to get the old version to build with e.g a new gcc.
> I think that if we are confident that the fixes/updated version are
> going to land but just are taking a bit of time there is no real reasons
> to block bugfixes to reach users on the stable serie...
> Does that make sense?

I think LibO and the kernel are pretty much the only examples where I
can understand and could tolerate this. It would set a precedent which
other people can point to though, and before we know it we are in the
situation that Ubuntu Touch was in the past when people never landed
new things in the devel series first and then fixes got lost, merging
was a pain, etc.

This is the only real point in time when this gets checked by a human,
beyond that we don't have any pressure on developers any more to land
in devel first.

In this particular LibO case this argument also doesn't work -- LibO
5.1.2 already *has* been uploaded to yakkety twice, and it clearly
does build with the new toolchain. There is no reason to assume that
5.1.3 is worse, and if it is, that's a regression that should be
investigated first.

I'd say that cases like this at least require prodding some SRU team
member with some good reason -- I wouldn't expect these uploads to get
accepted as part of the regular workflow.

That said, I accepted LibO for xenial-proposed now. But these kinds of
special cases are hard to track, don't stick around, and don't

Martin Pitt |
Ubuntu Developer ( | Debian Developer (

ubuntu-devel mailing list
Modify settings or unsubscribe at: