← Back to team overview

launchpad-dev team mailing list archive

Re: so many unmerged branches

 

On 09/23/2010 11:53 PM, Maris Fogels wrote:
> On 09/23/2010 12:19 AM, Martin Pool wrote:
>> I just noticed today there's something like 40 approved ready-to-land
>> reviews on <https://code.edge.launchpad.net/launchpad/+activereviews>,
>> with about 10 over a month old.  It seems like a lot.... Why do you
>> suppose they sit there for so long?
>>
> 
> Pure speculation here, but I think that it is partly a side-effect of
> distributed development: you can not easily see where the work is, or where
> undelivered work has built up.  We don't see or count the unmerged branches
> every day (no one person does), and the system, people, and process do not warn
> us when too much undelivered work has built up.
> 

...

> You could double-up the Andon system to warn you about the amount of undelivered
> code at each stage of development:
> 
>   Unlanded: xxxxxxxxxxxx
>   PQM:               xxx
>   Buildbot:           xx
>   QA:             xxxxxx
>   Undeployed:   xxxxxxxx
> 
> 

I just saw the flaw in my reasoning behind this idea.  First, I am going to
share my mistake with the list so that others can avoid making the same error in
the future.  Second, I have a proposal for dealing with the unlanded branches.

The mistake I made is believing that making the built-up inventory visible will
solve the problem: it won't.  Having a system that watches unlanded branches is
no better than pointing a video camera at a stack of boxes: someone still has to
get down there and move the stack; it is a safe bet that the video camera won't
get up and help you.  The inventory builds up because there is no process or
person in place to prevent it.  The cameras watching the pile will not stop it
from growing.  We need process first.

So I do not know how to keep the unlanded branches from building up, but I do
have an idea about how we can get them landed without sending nag mails to everyone.

My proposal is simple: we create a kanban card for every unmerged branch, then
we put those cards in each respective team's "Ready To Land" lane.  The teams
may then deal with the extra cards as they see fit.  This would create about 14
new cards, all for code that is more than ten days old.  We won't worry about
the extra cards blowing past the lane's maximum card limit - that is kind of the
point :)

Does anyone object to this idea, or see obvious flaws in it?  If not, I can put
the plan into action on Monday.

-- 
Māris Fogels -- https://launchpad.net/~mars
Launchpad.net -- cross-project collaboration and hosting

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References