launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Fri, 2011-04-15 at 16:59 +1200, Robert Collins wrote:
...
> Then it turned out we had a lot of special cases and we did some data
> fixing + code changes and made ProductSeries and DistroSeries
> mandatory - it was no longer possible to have a Product without a
> trunk (or something like a trunk) and likewise distros.

This is not true. Only 8 of the 33 distributions have series. We cannot
deactivate those unseries'd distros either. You will find critical bugs
where the root cause is a distro without a series. eg.
<https://bugs.launchpad.net/launchpad/+bug/277118>

...

> * Specific release branches only with trunk getting relabelled at each release
>   - This maps a little less well because all the bugs which were -not-
> fixed in a given release need to be promoted to the new focus when the
> focus is changed.

This relates to retargeting incomplete work when releasing a milestone.
<https://bugs.launchpad.net/launchpad/+bug/669662>

>   - It also would regress -slightly- in functionality because the
> current practice of nominating *into trunk* to identify special-case
> bugs would no longer work. However, using milestones for release
> planning would still work, as would using the critical importance, or
> tags.

But nominating a fix in trunk is insane, as is allowing nominations for
projects with only one series
<https://bugs.launchpad.net/launchpad/+bug/608856>

>   - It would also bring bug task management into line with how source
> packages and branches are handled at releases of projects using this
> model.

Users can delete series. Lp currently deletes the conjoined bugs. I
believe it attempts a retarget to the pillar. Lp blocks the deletion of
the development focus. What becomes of the bug targeted to deletable
series?

> Finally, here is what we could gain:
>  - drop the product and distribution columns from bugtask (2 ints * 900K rows)
>  - simpler check constraints
>  - simpler logic - bug targets would always be series objects not pillars.
>  - clearer constraints on bug reports: we have multiple situations at
> the moment where bugs are not clearly relevant/not relevant to a
> series. E.g. the open bugs report for Ubuntu - should it include bugs
> on natty (it doesn't). and bugs for natty (should it include open bugs
> on Ubuntu? (it doesn't)).

I will add that this model is simpler for users and will help explain
why they want a series. "Series" is still a strange concept to many
developers, who might otherwise have a good understand of branches. This
change will reinforce that bugs are in code, and that code is
represented a series for planning...

...there are projects that will never have code and even complain they
have to have series. These are projects create to use bug tracking an
specification planning to manage a team's tasks. I do not think this
change stops these teams from continuing to use projects without code.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part