launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Mon, 2009-11-02 at 16:36 +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...

If this was the reason, it is fatally flawed. For the past two years I
have worked in more than one application every release. During the
registry stand-up meetings I need to see the current milestone for
foundations, blueprints, answers, and registry.

I have been thinking about a change to milestones and team that allow me
to see a milestone in a projectgroup for the context of a team
(~launchpad-registry)

I am certain this problem affects any cross project team such as
documentation, design, or usability. This certainly is an issue outside
of Launchpad where for example, the gedit hackers own gedit,
gedit-plugins, and gtksourceview.

We have tags that represent components. Many registry bugs are still
tagged with registry-people and registry-projects

Also, I move bugs between lp projects, and I commonly must reset the
milestone after it was lost.

> 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
>   * confusing for users and new developers
>   * it's somewhat inauthentic
> 
> = The Solution =
> 
> Apparently we can't just switch. I don't know the reasons why not, but
> I assume that apart from inertia and what-not, that they are all bugs.

* Ensure no bugs and blueprints are targeted to series.
* Using SQL add a tag to each bug that represents lp.<app>
* Using SQL Update each FAQ to have a keyword that represents lp.<app>
* Using SQL update each bug, blueprint, question, faq to the lp project
  * In the case of bug and blueprint update the milestone to the lp 
    counterpart

PS. Using SQL to make series and milestone the to move bugs and
blueprints have cause me create heartache months later when I discovered
the production DB was in an invalid state.



-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part