launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Sat, Apr 16, 2011 at 3:04 AM, Curtis Hovey
<curtis.hovey@xxxxxxxxxxxxx> wrote:
> 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>

We should do for them what we did for products then - I clearly
misremembered the degree of fixing we did.

>> * 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>

I've marked that as dup of bug 341687 since they appear a complete
match to me. (341687 is about manual work being needed to retarget
unfixed stuff).

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

I agree; I've heard though that nominating the development focus is
exactly what Ubuntu do (or perhaps used to do) when identifying
must-fix-during-release-leadup bugs. I suspect a net win by
eliminating this, but also that we need to check first :)

>>   - 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?

Same thing I'd assume: retarget to the pillars current development
focus. This sounds unexpected to users when we describe it like this,
so I think we'll want to (as a separate iteration) improve our
handling of deletions. Perhaps:
 - mark the series deleted but do not remove; just don't show in the
ui unless deep linked to
 - leave the bugtask on the 'deleted' series but stop aggregating it
to the project, stop showing in searches
   and stop showing the series task on the bugtask:+index form.
 - mark the page specific to the bugtask & deleted series up as
do-not-index for google etc

The two combined would;
 - allow old links to work
 - allow mistakes to be non hugely destructive
 - get rid of the work from general view

We could have a stronger 'really delete' for folk that currently mark
the bugs as private and unsubscribe everyone.


> ...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.

I agree; and in planning situations you still may be planning
different things that are only slightly related; folk could user
series for that if they wanted.

-Rob