launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

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.

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.

-Rob