On 11 November 2010 19:51, Robert Collins <[email protected]> wrote: > On Thu, Nov 11, 2010 at 4:24 PM, Max Kanat-Alexander > <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
