-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Lange wrote on 02/11/09 19:02: > > On Mon, Nov 2, 2009 at 5:36 PM, Bjorn Tillenius <[email protected]> >... >> On Mon, Nov 02, 2009 at 04:36:17PM +0000, Jonathan Lange wrote: >... >>> Launchpad has a project group called 'launchpad-project' and many >>> subprojects, one for each team or component (depending on how you >>> want to slice it). Examples include malone, soyuz and >>> launchpad-code. However, there's really only one project, >>> 'launchpad', which has its code in one place. >... >>> But there are all sorts of negative consequences from us going >>> against the grain of Launchpad's design: >>> * the dupe finder works poorly >>> * milestones and series are harder to manage overall, since they >>> have to be duplicated >... >> I'd say we are already dogfooding. We're dogfooding how to use >> project groups. Sure, it might not be the best way of using project >> groups, but what is the best way? I though that projects within a >> group is usually quite closely related, no? Thus you want the dupe >> finder to work across project groups, no? And you want to be able to >> create milestone across project groups, no?
Throughout our design process in 2005 and 2006, our routine examples for project groups (then known as "projects") were Gnome, KDE, and Mozilla. For groups like those, you would not want the dup finder to work across the project group; for example, it would make no sense for a bug search in the Totem project to turn up bugs reported on Cheese, or for a bug search in the Fennec project to turn up bugs reported on Thunderbird. And you would want to share milestones across the Gnome project, but not the other two. Now, those may not be realistic examples of project groups that will ever adopt Launchpad. In that case, I suggest stepping back and thinking about sharing and subdivision in general, without using the words "project" or "project group". Sharing: What things do you want to want to share across codebases, and how often? Milestones? Branches? Bug search results? Bugs? Blueprints? Announcements? Launchpad has ad-hoc mechanisms for sharing bug reports and translations across projects. Are groups the best way of solving other sharing problems? Subdivision: In what situations are people interested in, or limited to, a particular area of a codebase? For example, checking in code to Mozilla's security components used to be (and may still be, I don't know) restricted to a smaller group of people than the rest of the codebase; is that something Launchpad Code should support? Curtis Hovey is interested in bugs in Foundations, Blueprints, Answers, and Registry, while Diogo Matsubara may be interested in oopses and timeouts across the codebase; what is the best way of supporting those classifications? >... > Either way, I still want to get clear on what the bugs actually are. > And trust me, there are bugs that have been filed along these lines > already. >... If you conclude that the launchpad-project projects are being used because bug tagging isn't convenient enough, and that tags are a better solution than categories, then <https://bugs.launchpad.net/malone/+bugs?field.tag=bugtag> comes close to listing "what the bugs actually are". One possibility to consider, though, is that the same tags a project uses for its bug reports should also be usable for its branches (to attract the appropriate reviewers), questions (to attract the appropriate answerers), and blueprints. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrwJRcACgkQ6PUxNfU6ecpL7ACeKDhmztsMd8XOECUaXR915CvH fa4AoIpxKUDlQXEz7odaL1L3/R0FGawF =4RRm -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
