This isn't deeply thought out, but I wonder if we can get rid of 'product', 'distro' and 'distrosourcepackage' bugtasks (and thus conjoined masters). If this mail gets a reasonable level of interest, I will LEP this up and socialise it more widely.
More concretely, when we built malone we had the idea of a 'bug in a package', 'bug in a project' and 'bug somewhere in Ubuntu'. We also wanted to be able to model bugs in prior releases, or in different long term parallel releases and that turned into both series tasks and per-version data [which we haven't got in the system today - also known as infestations]. In the very early launchpad there was /no/ requirement for series. ProductSeries was an optional extra. 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. So it seems to me, that in our current model, if we moved *all* the product bugtasks onto their trunk series; and ditto Ubuntu tasks to be natty tasks, and lastly Ubuntu sourcepackage bugtasks to be Ubuntu natty sourcepackage bugtasks, we could remove the concept of 'Pillar as a whole' bugtask. Why would we do this, and what about when releases happen? Making this simpler would make Launchpad easier to understand, easier to develop on, and faster. There are four main release models I've seen: * Don't: run trunk or go home. - launchpad * Trunk is always releasable, releases are snapshots of trunk. - bzr in the past * Make a branch from trunk at-or-before-release, and the release is on the branch, point releases carry on on the branch. - bzr now - Debian - Fedora * There is no trunk, only specific release branches including one whose name/number is that of the next intended release. - Ubuntu So the question is how this would map into each of those four models. * Don't: - maps easily: tasks are on a single series * Snapshots of trunk - also maps easily: use milestone based releases to capture the bugs included in a given release. * Branch before release - Maps easily: make a new series when the branch is made and use nominations to bring across bugs from trunk which also affect the release series and need fixing before release. [Or backporting]. * 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. - 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. - It would also bring bug task management into line with how source packages and branches are handled at releases of projects using this model. 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)). -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
