Cannot start developing next ubuntu release before the prior one is released

This feature is planned to be in place only for Festy+2

FYI: The distro team has asked us politely if we can get to this sooner than later as it would make their lives a bit easier.

raising to medium as this affects the distro team and has been requested by them

When there will be an ability to register new release (or milestone) for other distros in launchpad ?
Without having an ability to register releases or milestones launchpad can't be used as bug tracking system for other distros (e.g. Elbuntu, Fluxbuntu, Baltix - look at https://launchpad.net/distros )
It's too hard to track bugs when there are no ability to set the target milestone :(

@mantas please file a new bug.

On this bug itself, I wonder if derived distributions has delivered all the bits and it just needs glue now?

It's actually quite possible, yes. We should get someone from distro to assess it.

Things are better now, although the current workflow is still clunky. We can now create the next distroseries along well in advance and set its status to FUTURE, which allows us to do things like target bugs to it. That's certainly useful.

However, as far as actually preparing packages goes, what we do at the moment is prepare them in a non-virtualised PPA which thinks it's for the previous distroseries, and copy them into the new distroseries once it opens properly. This at least doesn't involve a separate dak instance or anything like that, and it has allowed us to open the next distroseries within around a day of releasing the previous one for a couple of releases running now; but it's error-prone and rather confusing (why does this changelog say oneiric when it's the toolchain for precise?), and is not really sanely extensible to anything beyond the core toolchain. If we were able to open the next distroseries for real before releasing the previous one, then we could (for example) usefully get the initial mass sync from Debian in place in advance. The current approach wouldn't scale to that kind of thing.

I would still like to be able to upload directly to the next distroseries along and bring the ancestry up to date incrementally. If there are unexposed facilities for this in Launchpad, I'm happy to assess them given pointers.

So, I think it needs some assessment of the impact on soyuz plumbing - I suspect there are some hard coded facilities to fix.

In short though, AIUI, you want:
 - a non-frozen distroseries folk can upload to
 - that doesn't become trunk.
 - and starts off as a clone of the current trunk in terms of content
 - and can have (perhaps automatically?) new packages in trunk copied into it.

On Mon, Dec 19, 2011 at 07:33:24PM -0000, Robert Collins wrote:
> So, I think it needs some assessment of the impact on soyuz plumbing - I
> suspect there are some hard coded facilities to fix.

Indeed. This is certainly a process optimisation rather than anything
essential, at this point (given the set of workarounds we've
established); I wouldn't want to compromise correctness or features
elsewhere for this.

> In short though, AIUI, you want:
> - a non-frozen distroseries folk can upload to
> - that doesn't become trunk.
> - and starts off as a clone of the current trunk in terms of content
> - and can have (perhaps automatically?) new packages in trunk copied into it.

Right.

If and when somebody gets to this, we should think about how to present
the case where history diverges after the initial clone. We might just
be able to deal with that manually, and that would probably be
acceptable, but maybe there are better ways too. I also don't know the
exact semantics of the package ancestry stored in Soyuz and what ought
to happen to it in such a case.