r398 uploaded and awaiting ubuntu-release team approval

[Kapil Thangavelu]

Excerpts from Clint Byrum's message of Sun Oct 09 23:34:26 -0400 2011:
> Excerpts from Kapil Thangavelu's message of Sun Oct 09 15:07:50 -0700 2011:
> > Excerpts from Gustavo Niemeyer's message of Sun Oct 09 17:06:58 -0400 2011:
> > > > Hi everybody. Just an FYI that I've just uploaded what should be the final
> > > > release version of Juju for 11.10, which is revision 398. When it lands
> > > > do remember to update your environments.yaml to have default-series:
> > > > oneiric, and also change juju-branch: to juju-origin. Any automated
> > > > scripts will also need to be updated to use 'local:$charm_name' instead
> > > > of just '$charm_name'. If you see that 'store.juju.ubuntu.com' is not
> > > > resolvable, that is because local: is no longer the default charm source.
> > > 
> > > Thanks for taking care of this Clint. It'd be good to have at least
> > > the following branch merged as well as it'll make people stumble less
> > > upon apt-get's interactivity:
> > > 
> > > https://code.launchpad.net/~hazmat/juju/hooks-with-noninteractive-apt/+merge/78592
> > > 
> > > It's ready for merging, and I can move ahead and merge it if you'd
> > > like to do it before tomorrow once Kapil is around.
> > > 
> > 
> > There's one more important bug fix for the release in the review queue.
> > https://code.launchpad.net/~hazmat/juju/local-provider-storage/+merge/78652
> > 
> > It solves an issue for charm upgrades when using the local provider.
> > 
> > I'll go ahead and merge the non-interactive apt hooks branch shortly.
> 
> r398 was accepted and is in 11.10, and will be the one that the release
> ends up with unless in the next 24 hours we find that it rm -rf /'s or
> something horrible like that.
> 
> The deadline for the release is already quite a bit in the past.. we
> didn't have to do anything drastic like appeal to the Tech Board to
> bypass normal procedures only because a member of the release team had
> time to review and accept r398, and universe allows such exceptions up
> until some time this Tuesday. I'd love to actually get some testing in
> over the next 24 hours, rather than spend more time merging in fixes.
> 
> Given the number of tasks the release team has and the backlogs of things
> I personally have for the release, I'd suggest we start preparing a list
> of bugs for SRU shortly after the release.
> 
> 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?


> 
> 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.

cheers,

Kapil