r398 uploaded and awaiting ubuntu-release team approval

Clint Byrum clint at ubuntu.com
Mon Oct 10 03:34:26 UTC 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.

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

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.



More information about the Juju mailing list