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

Bug #87012 reported by Celso Providelo
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

Open a new DistroRelease earlier than releasing the current one is wanted because new technologies can start to be rounded even before the official development cycle allows.

However most of the features and fixes landed on the current development release should be imported in the incrementally on the new development release.

For being able to perform incremetal initialisation we need to modify the initialiseFromParent workflow. It should copy only missing source and binaries publication from parent. The Domination procedure will filter the publications appropriately letting only the most recent ones in PUBLISHED state.

Currently this feature requires duplicated infrastructure (dak-based).

Revision history for this message
Celso Providelo (cprov) wrote :

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

description: updated
description: updated
Changed in soyuz:
importance: Undecided → Wishlist
status: Unconfirmed → Confirmed
Revision history for this message
Joey Stanford (joey) wrote :

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.

Revision history for this message
Joey Stanford (joey) wrote :

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

Changed in soyuz:
importance: Wishlist → Medium
Revision history for this message
Mantas Kriaučiūnas (mantas) wrote : When there will be an ability to register new release (or milestone) for other distros in launchpad ?

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 :(

Revision history for this message
Robert Collins (lifeless) wrote : Re: Opening a new distrorelease before releasing the previous one

@mantas please file a new bug.

Revision history for this message
Robert Collins (lifeless) wrote :

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

Changed in launchpad:
importance: Medium → High
summary: - Opening a new distrorelease before releasing the previous one
+ Cannot start developing next ubuntu release before the prior one is
+ released
Revision history for this message
Julian Edwards (julian-edwards) wrote :

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

Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Revision history for this message
Robert Collins (lifeless) wrote :

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.

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 87012] Re: Cannot start developing next ubuntu release before the prior one is released

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.