On Sat, Apr 16, 2011 at 3:04 AM, Curtis Hovey <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
