r398 uploaded and awaiting ubuntu-release team approval

Clint Byrum clint at ubuntu.com
Mon Oct 10 17:04:12 UTC 2011

Excerpts from Kapil Thangavelu's message of Mon Oct 10 08:46:48 -0700 2011:
> Excerpts from Clint Byrum's message of Sun Oct 09 23:34:26 -0400 2011:
> > To mark a bug for that process, make sure to click "also affects
> > distribution" and nominate it for Oneiric so we can collect all of the
> > SRU fixes that need to be done, otherwise I have to go digging for all
> > of them. I'd suggest that any bug fixed in the next week or so be added
> > to this list, so we can just merge trunk in again rather than having to
> > specify all the changes individually and/or cherrypick.
> > 
> Sounds good, the release dance must end, so the next can begin.
> I've marked the sru bugs (merged since 398 and still pending) against the 
> distribution of juju and the oneiric updates milestone.
> > To pass the normal SRU process, each issue needs a clear test case which
> > can be performed by a 3rd party (not the SRU team, and not the developers
> > coding the fix).
> Sounds good. Is the proper place for this reproducing test case the bug report?


You don't need to do the full justification on each one, but a


#. do foo
#. then bar

helps verifiers find the test case, and goes in the bug description.

> > 
> > The alternative is to ask the tech board for an exception to the SRU
> > process.  Given Juju's nature as a leaf package with excellent test
> > coverage and its strategic position in Ubuntu Server's future, I think
> > this should be a slam dunk.
> > 
> > Anyway, until we work that out, probably best to start queuing them up
> > as normal SRU's to reduce friction and get these fixes out rapidly.
> > 
> A bit more broad of a question is how many SRUs do we want to do for oneiric. 
> We've got a two pending changes, that we can get merged (or already are) sequentially trunk 
> before new features are merged.
> After that though, we're not currently maintaining a stable release branch 
> against oneiric so additional SRUs won't be possible.

So one thing to consider is to religiously keep backward compatibility
with the Juju in r398.  Then we can simply keep SRU'ing the whole of
Juju without worrying about breaking peoples' test setups. This will
require two things I think:

1) Automated integration testing that doesn't change (meaning, make sure
it works on 11.10 release, and that it keeps working in the SRU versions).

2) Testing cycles in between dev cycles so we can invite users to test
with their own setups before we do updates. That can be the -proposed
period, but I think we might want to actually have a week or two of lead
time before we upload to -proposed to catch obvious problems.

I think if we have those two things, the regression potential argument
against features piggy-backing on SRU's can be waived. This is somewhat
like the Firefox process, but perhaps a bit more difficult to keep sane
since one is managing the juju installed on remote nodes, and there is
no defined process for updating the agents.

More information about the Juju mailing list