launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Nov 2, 2009 at 5:36 PM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> wrote:
> On Mon, Nov 02, 2009 at 04:36:17PM +0000, Jonathan Lange wrote:
>> Hello Launchpadders,
>>
>> One thing we talked about at the team lead sprint a few weeks back was
>> what would it take to dogfood Launchpad for real. The result of the
>> discussion was that it would be a fair chunk of work and wouldn't
>> deliver much of value to most of our users.
>>
>> With my Product Strategist hat on, I agree.
>>
>> But let's just say that I didn't agree. Well, then I'd write an email
>> an awful lot like this:
>>
>> = The problem =
>>
>> 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.
>>
>> The reasons we don't just have one project, AIUI, are:
>>   * too hard for teams to manage their bugs -- too much clutter
>>   * ummmm...
>>
>> 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 wouldn't say these are problems that will be solved by abandoning the
> use of a project group. Sure, it might make the problem go away for us,
> but will it make the problem go away for other people using project
> groups?
>

I don't know of any other people who use project groups to manage a
single codebase.

> 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? I think these are issue that we should really fix,
> not work around them. Or is the grand plan to get rid of project groups
> altogether?
>

Removing project groups is not in the grand plan.

However, I'm led to believe that we actually would not allow people to
create a project group like the one we've created for Launchpad.

I think I understand your point though: if we're using Launchpad in a
way that it's not designed for, either we can change to use it as it's
designed, or we can change Launchpad so that it's designed for both
uses. Is that right?

I personally strongly dislike having projects that aren't linked to
code (or docs or some sort of shared artifact), and very much like the
idea of "one codebase corresponds to one project". This is an
instinctive aesthetic response that I can't back up right now, but am
happy to hammer it out in the forge of enlightened discourse.

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.

>>   * confusing for users and new developers
>>   * it's somewhat inauthentic
>
> I don't know what you have in mind here. In what way is it confusing,
> and is that also something that we maybe should fix, rather than work
> around?
>

What I mean by confusing is perhaps demonstrated by the non-intuitive
answers to the following questions:

Q. Where do you file bugs against Launchpad?
A. On 'launchpad' if you don't know, on the subproject if you do know.

Q. Where do you get the code from?
A. The 'launchpad' project. It doesn't have any bugs though, they're
against different projects.

Q. If you've found a bug in the 'malone' project that you want to fix,
where do you get the code?
A. The 'launchpad' project.

Q. Where do you search for bugs against Launchpad?
A. 'launchpad-project'. Note that you cannot file a bug there.

Maybe we should fix these.

Thanks for posting such a thought-provoking reply :-)

jml