launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 11 November 2010 19:51, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> On Thu, Nov 11, 2010 at 4:24 PM, Max Kanat-Alexander
> <mkanat@xxxxxxxxxxxx> wrote:
>>        Hello all. I have now created a stable 1.18 branch for loggerhead:
>>
>>        lp:loggerhead/1.18
>>
>>        This branch will take only small bug fixes--no large refactorings, no
>> feature additions, and no complex-but-low-priority fixes.
>>
>>        Starting now, this is the branch that codebrowse should be running.
>> (You can update codebrowse to be based on this branch immediately.) If
>> there are significant stability issues that we can address with
>> straightforward fixes, we will fix them on the branch and then can
>> deploy them to codebrowse.
>>
>>        If you plan to commit things to this branch, I'd appreciate being
>> tagged as a reviewer.
>>
>>        If you have any questions, please let me know.
>
> I'm very glad you've done a new release. I have some logistical concerns.
>
>
> We run dedicated branches of our dependencies, so that we can:
>  - review from within our group of 20+ reviewers
>  - react and deploy things promptly
>
> On reviews:
> Your request above *appears* to put you in as a bottleneck here, which
> is inefficient vs having a large group of reviewers that can be
> tapped. I'd want a very strong reason to do that. Perhaps I'm
> misunderstanding what you're actually asking.

I think he meant just "I would like to be asked" - it should be enough
for Max to be subscribed to the target branch to get told?

If other people do reviews and Max also reads the review comments that
seems ideal.

I would hope we all agree that people should never tolerate being
stalled waiting for review: demand that someone review it, or if you
can't get that, merge without review.

> On deployments:
> We should only deploy changed versions when we've performed QA to
> satisfy ourselves we're happy with the new version being deployed.
> Running 'trunk' of something is fine, as long as we don't deploy
> arbitrary versions: we have to explicitly choose to switch to a newer
> rev. Likewise, running a release branch is fine - but we still need an
> explicit step when we deploy a new version of something. If you can
> propose a merge to Launchpad of a dependency change when a new version
> is ready (see our versions.cfg - its a buildout based approach); then
> check it works on on qastaging (or tell other folk what they need to
> look for and they can qa it) - that will fit in with our processes.

istm we want an upstream 1.18 branch, then a Launchpad-specific "this
is what we run" branch, that intermittently pulls or merges from
upstream stable.  If this process is working well, we should rarely
need any divergence other than upstream stable running a little bit
ahead: anything Launchpad wants to fix should be targeted at 1.18, and
anything into 1.18 should be safe for deployment (after testing.)  If
those two aren't aligned properly we should communicate and bring it
into alignment.

-- 
Martin