launchpad-dev team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 09/23/2010 12:03 AM, Jonathan Lange wrote:
> On Thu, Sep 23, 2010 at 7:48 AM, Ian Booth <ian.m.booth@xxxxxxxxx> wrote:
>> On 23/09/10 14:19, 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?
>>>
>>
>> One reason is lack of process enforcement. I realise launchpad tries to
>> be fairly loose with mandating process and relies on social enforcement.

Process enforcement is fine, but process automation is better.

>> But maybe an option could/should be added? To stop people forgetting to
>> land their approved branches, should nag emails to the proposer be sent
>> out after a set time has elapsed? Then, after X emails with no action,
>> perhaps an email to the project owner? Or something?
>>
> 
> Perhaps. There's a large amount of anecdotal evidence from within the
> Launchpad that suggests that automated nagging emails don't work.

And I agree - nagging emails don't do a bunch.

>> In terms of RACI methodology
>> (responsible/accountable/consulted/informed), if there is no one
>> accountable for managing a certain change/action (in this case landing a
>> branch), then there's strong likelihood it won't get done.
>>
> 
> If you own the branch, it's your responsibility to get it landed or to
> abandon it. Even if you don't have commit privileges, it's your
> responsibility to find someone who does and get them to do it.

FWIW, we've had really good luck in Drizzle with having a rotating merge
captain who does the landing of approved branches ... and while they're
handling merges that's all they do. I plan to replace that merge captain
with a program as soon as I can.

Although I appreciate the principal of being responsible for follow
through, I'd argue that developers do not tend to be good at is
following manual processes.

Monty