Series, releases, and milestones overlap confusingly

Reported by Matthew Paul Thomas on 2007-12-06
32
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

In Launchpad, series are containers for releases and milestones, which are separate types of object. Some things can be done for releases but not for milestones, such as tracking bugs separately for porting purposes. Other things can be done for milestones but not for releases, such as scheduling bugs and blueprints. This is awkward and confusing, to the extent that it fails the dogfood test: Launchpad itself uses milestones for what are actually releases.

One possible solution:
* For both distributions and projects, a series is a collection of milestones.
* A milestone has a toggle for whether it is a release or just a scheduling point.
* When a series is registered, it automatically contains one release milestone with the same name as the series, though this can be renamed or deleted if necessary.

A real-world distribution example: Ubuntu would have a "Hardy" series consisting of milestones "Alpha 1" through "Alpha 6", "Beta", "8.04", and likely also "8.04.1" and "8.04.2". At least the last three of these milestones would be marked as releases. (Reference: <https://wiki.ubuntu.com/HardyReleaseSchedule>.)

A real-world project example: WordPress would have a "mainline" series with "2.4", "2.5", and "2.6" release milestones, together with "2.2.3", "2.0.12", "2.3.2", "2.0.eventually" etc non-release milestones. (References: <http://wordpress.org/about/roadmap/>, <http://trac.wordpress.org/roadmap>.)

See also bug 99994 and bug 138994.

Séverin Lemaignan (skadge) wrote :

+1 for this bug

Joey Stanford (joey) wrote :

+1

Joey Stanford (joey) wrote :

I'm setting this to confirmed because it is a genuine problem. There needs to be further discussion as to the solution before it can be officially put into triaged status.

Changed in launchpad:
status: New → Confirmed
Mark Shuttleworth (sabdfl) wrote :

This sounds good in principle. Remember, we want to add DistroRelease (as a cache-point for all the package versions current at the time of the release) so there will be symmetry between our upstream ProductRelease and the distribution DistroRelease.

I'm quite happy for "Add Release" to disappear from both Distro and Product action menus, and for that to become a "Publish release" wizard on the milestone page which creates a new Product/DistroRelease from that milestone.

Perhaps the milestone-on-trunk-series should be called "future" ? One issue there - I had very much intended to do away with dateless milestones, so that every milestone gets an explicit target date. Please figure out how that gels with "future" on trunk. I would recommend reconsidering having a milestone by default, I don't think it's semantically meaningful in the same way that trunk is meaningful.

Mark

Dennis Schridde (devurandom) wrote :

I second this.

Gustavo Niemeyer (niemeyer) wrote :

We use milestones for releases too. Something like the proposed scheme would be good.

description: updated
Changed in launchpad-foundations:
assignee: nobody → edwin-grubbs
milestone: none → 2.1.10
status: Confirmed → In Progress
Curtis Hovey (sinzui) on 2008-10-07
Changed in launchpad-foundations:
milestone: 2.1.10 → none
Changed in launchpad-registry:
importance: Undecided → High
milestone: none → 2.1.11
Lionel Dricot (ploum) wrote :

I would also like to add to it's currently impossible to move a milestone from one serie to another or to remove a milestone. And yes, the whole scheme is very complex compared to Trac milestones.

Curtis Hovey (sinzui) wrote :

This bug has a lot of smaller bugs and features that must land before we can consider this fixed. I expect this to really be fixed in the 2.2.1 release.

Changed in launchpad-registry:
milestone: 2.1.11 → 2.1.12
Changed in launchpad-registry:
milestone: 2.1.12 → 2.2.2
Curtis Hovey (sinzui) on 2009-02-23
Changed in launchpad-registry:
milestone: 2.2.2 → 2.2.3
Edwin Grubbs (edwin-grubbs) wrote :

Landed in rev 7801 in db-devel branch.
revision-id:<email address hidden>

Changed in launchpad-registry:
status: In Progress → Fix Committed
Lionel Dricot (ploum) wrote :

Could you describe (maybe on the launchpad blog) what have been done to "fix" this bug and what changes we will see ?

Thanks for the work !

Changed in launchpad-registry:
status: Fix Committed → Fix Released
Changed in launchpad-registry:
status: Fix Released → New
Matthew Paul Thomas (mpt) wrote :

This is not fixed. Steps to reproduce:
1. On <https://staging.launchpad.net/>, register a test project.
3. From the project page, choose "Register a series", and enter the series details.

What happens:
* The series page contains both a "Create [sic] milestone" link and a "Create [sic] release" link.
* The form for registering a release says "A release requires a corresponding milestone that is not attached to another release."

What should happen:
* The series page contains a "Register a milestone/release" link.
* The form contains a checkbox for whether the milestone represents a release.

Edwin Grubbs (edwin-grubbs) wrote :

If you have javascript turned and are not running IE, there should be a green "Create milestone" link next to the milestone drop-down list on the "Create release" page. Instead of using an ajax formoverlay, we could combine the fields into one form, so that it does not require two form submissions.

Changed in launchpad-registry:
assignee: Edwin Grubbs (edwin-grubbs) → Curtis Hovey (sinzui)
Curtis Hovey (sinzui) on 2009-08-31
Changed in launchpad-registry:
status: New → Triaged
importance: High → Low
Curtis Hovey (sinzui) on 2009-09-09
Changed in launchpad-registry:
milestone: 2.2.3 → none
assignee: Curtis Hovey (sinzui) → nobody
Paul Sladen (sladen) wrote :

Perhaps the solution here would be the removal of directly adding releases; everything added would be a milestone (as appears to be case for how LP is being used), and milestones could be [x] ticked as having been released. The historic releases could stay, but in future the user would be guided towards milestones exclusively.

Yes, I think there's goodness in this proposal.

Curtis Hovey (sinzui) wrote :

Paul, your suggestion is mostly implemented. Launchpad has been hidding the separation between milestones and releases for more than a year. The "Create a release" link on series pages is creates a milestone and asks the user to provide release notes.

I understand though that you wanted to create a milestone from the +milestones page. The milestone belongs to a series. So to implement this feature we need a new form that asks you to select or create a series while creating a milestone (and include the the 3 release fields).

Releases and milestones have subtly different behaviour; so attempting
to "hide the differences" is (I suspect) contributing to the problem
not solving it. If the _only_ cycle possible was a purely linear one:

  Create -> Milestone -> Release -----+
  Delete <- Milestone <- Unrelease <--+

then I think this would help to stop tripping up as there's less
code-paths for the user to get their head around. It would remove the
weird two-stage stacked dialogue currently presented when creating a
release.

Since a release (seems to) require a milestone, one user could simple
select their existing milestone and "(+) Release" it. This way the
two steps are /genuinely/ two steps, rather than being forced on the
user as a double-stacked dialogue.

(Chris: the issue of discoverability is separate and →bug #40497)

Curtis Hovey (sinzui) wrote :

Users can select a milestone and release it. I see the (+) Create release on all the milestones for projects I maintain or am the release manager for. A form is displayed for me to add release notes and changelogs, but I ignore those field since the milestone already shows the targeted bug and blueprints.

I do not think the problem is about the differences of milestones and releases (I have argued that a release is just a milestone that achieved a special state).

I think the problem is the ambiguity of series. Users have a fair understanding of projects and that the software are released as versions. Series are a planning devices that track a branch and organises features and fixes into milestones. A lot of projects do not plan their work using the series model. They either do work, then want to create a release, or in some cases, do work, then create a series to track backporting and add a release.

Regardless of whether projects use series or not, I think every user would like to be able to create a release from their project's +index and +milestones pages. The user can provide the minimum information needed to register a release, but is encouraged to provide release notes, files, and make an announcement to promote the work.

> (I have argued that a release is just a milestone
> that achieved a special state).

I am in total agreement.

> I think every user would like to be able to create a
> release from their project's +index and +milestones pages.

I wholeheartedly support this too, I believe it is bug #40497.

 On 25/09/10 13:44, Curtis Hovey wrote:
> I understand though that you wanted to create a milestone from the
> +milestones page. The milestone belongs to a series. So to implement
> this feature we need a new form that asks you to select or create a
> series while creating a milestone (and include the the 3 release
> fields).

The workflow mockups we did a long time ago showed how to do nested
creation, like creating a series in order to create a milestone.

Mark

Curtis Hovey (sinzui) wrote :

Yes, that is the solution I advocate.

Curtis Hovey (sinzui) on 2010-12-04
tags: added: milestones releases series
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers