launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01898
Re: process experiment proposal - move all our bugs to launchpad.net/launchpad
On Fri, Nov 27, 2009 at 5:55 AM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> wrote:
> On Fri, Nov 27, 2009 at 08:20:45AM +1100, Robert Collins wrote:
>> Is it feasible?
>> ---------------
>>
>> Launchpad-project has 5800 bugs, and ~30 developers, or about 19 bugs
>> per developer. bzr (core, not plugins) has 1800 bugs, and <10 developers
>> developers, or about 18 bugs per developer. bzr hasn't split its bug
>> database and the developers manage to get things done quite
>> successfully :)
>
> I actually don't think that number or bugs in total, or number of bugs
> per developer is that important. It's like you say, 1800 bugs isn't
> that different from 5800. Sure, 3 times more, but we also have three
> times the developers. What's important is the number of developers.
> Coordinating the work for 30 developers so way way much harder than
> coordinating the work for <10. It's not 3 times harder; it's more than
> that. That's why we divide the LP team into sub teams, so that the
> coordination work actually gets feasible to do.
>
I agree that we need to be able to coordinate work by teams smaller
than "all the Launchpad committers".
However, I do think that ideally, we'd be modelling this by using
teams. At the moment, we are modelling it with projects. I don't think
there is any real sense in which, malone say, is a separate *project*
from registry. It grates on me that we model it that way in Launchpad.
Ideally, we'd have one project (launchpad) and many teams, and work
could be coordinated through teams. Would you agree with this?
I think the next questions about whether the benefit of changing is
greater than the cost, whether we can do a cost-effective experiment
and what are the next actions are all interesting, but kind of futile
to discuss unless we know where we stand on the first question: what
would the ideal set up look like?
jml
Follow ups
References