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/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
