bzr 2.0.2 ubuntu StableReleaseUpdate

Robert Collins robertc at
Mon Dec 14 09:01:20 GMT 2009

On Mon, 2009-12-14 at 19:33 +1100, Martin Pool wrote:
> OK, I put a proposed package onto
> <>.
> One thing we identified in feedback is: all changes must be justified
> by a bug report with (if at all possible) a clear reproduction recipe
> in the description so they can be tested.  Not all of our changes have
> bugs associated with them.  It's not mandatory for trunk but we should
> check all proposed merges to the stable branch have a bug report.
> This isn't something anyone did wrong, just an improvement from here
> on.

Is this based on Martin Pitt's comments? I didn't read them quite the same way.

Remember too that this is from an Ubuntu perspective - so simply having
'bugs' won't be sufficient - they need to be bugs 'in Ubuntu', if that
is indeed the case.

AIUI though, the key objectives from the Ubuntu side are:
 - assess the risk of destabilising existing users
 - check the problem is indeed fixed.

For the former, I think our existing policy of only putting low risk
changes into stable branches is sufficient, and shouldn't need changing.
Adding a bug report as housekeeping isn't particularly efficient, and
crucially - makes doing the SRU /harder/ because there is another case
for the Ubuntu folk to check and sign off on.

For the latter, having a test that we added or changed when we made the
bug fix should be enough most of the time, but we can certainly consider
having a small script.

I think we should feel happy to talk with the Ubuntu devs in more detail
about this: what we want to achieve using an SRU is not what SRU is
designed to do - and so we should be precise about how things are
fitting/not fitting and crucially why certain things are looked for.

[Puts on Ubuntu dev hat]
For instance, the need to check the bug is fixed comes from having
patches in projects that are not heavily tested thrown at us, with no
QA, and a plea to 'SRU this'. Destabilising our immense userbase by
putting a change in via an SRU is a very significant risk.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : 

More information about the bazaar mailing list