[RFC] Releases planning

Max Bowsher maxb at f2s.com
Fri Oct 8 00:02:40 BST 2010


On 07/10/10 16:47, Vincent Ladeuil wrote:
>>>>>> Martin Pool <mbp at canonical.com> writes:
> 
>     >> +
>     >> + * there should not be more than 2 releases in the same week (but the
>     >> +   Release Manager is free to ignore this (get in touch with packagers
>     >> +   though),
> 
>     > Do packagers prefer this rule?
> 
> Yes, I'd like to know too :) Hey packagers ! What do you think ?

Most scenarios of packaging do not package all released series,
generally sticking only to latest stable and latest beta. Thus, it's not
really an issue.


> I discussed at length with pitti about the 2.0.6 SRU
> (https://bugs.launchpad.net/bzr/+bug/582656) and I think we should
> indeed focus on 2.2 and 2.3 and do only source releases for 2.0 and 2.1.
> 
> That is, depending on the OS we're packaging for, most of our efforts
> should be on the *last* stable release (2.2 today) and on the upcoming
> release (2.3 today).
> 
> I still think we should finished the current SURs, but after that, we
> can alredy discuss:
> 
> - still backport or target critical fixes to 2.1 (no more 2.0 backports
>   unless a very strong need arise) but we won't *package* it anymore,
>   we'll do only source releases.
> 
> - still backport bugfixes targeted at debian or Ubuntu for the 2.0
>   series, but in the packaging branch instead of our lp:bzr/2.0 or
>   lp:bzr/2.1 branches... which would make a good dogfood exercise...

I submit that 2.0 is of zero interest at this point. Ubuntu lucid and
Debian squeeze are on 2.1.x. The only Ubuntu series on 2.0 is karmic,
which has a mere ~6 months of support left.


>     >> +   Note that we also propose the most recent
>     >> +   stable series via the ppa, so whether we keep supporting LTS directly
>     >> +   or via the ppa is still an open question.
> 
>     > That sentence is not very clear, but I think you mean that when an LTS
>     > is say three years old, the only way to get new fixes will be to
>     > upgrade from the PPA.  I think that makes sense, especially if we have
>     > a ppa for each bzr series.
> 
> Almost, I was saying that instead of waiting for 2.0.6 for hardy, people
> could use the stable ppa and update to 2.2, but I think your idea is
> better :)

I think there is some misunderstanding here, the 2.0 series is not
associated with hardy.

> We could indeed create a ppa for each stable series and update it when
> we release a new stable series. That would ensure that our users get a
> coherent set of plugins with bzr itself (which the SRUs don't offer).

I would like to strongly suggest that we do NOT create a PPA for each
stable series. It would GREATLY increase the PPA maintenance burden, and
it's unclear to me that there are any scenarios where a PPA user cannot
update to the latest stable series.


Max.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20101008/78f7aaac/attachment.pgp 


More information about the bazaar mailing list