launchpad-dev team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----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 <bjorn@xxxxxxxxxxxxx>
>...
>> 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-----