launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On November 11, 2010, Max Kanat-Alexander wrote:
> > 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.
> 
>         Okay, but that would be done by somebody other than me--one of the
> LOSAs, perhaps, or somebody who works on Launchpad itself. I don't (and
> don't really desire) access to any of the proper systems to accomplish
> all those things. The details of the Launchpad loggerhead deployment
> have always been handled by the LOSAs, and I don't see any reason to
> take that away from them.

The good news is that you don't need any special access.

The process to trigger deployment would be:

1- You branch lp:~launchpad-pqm/loggerhead/devel, merge 1.18 in and push it to 
Launchpad. You propose that new branch for merging in lp:~launchpad-
pqm/loggerhead/devel

2- A LP dev will approve and do the actual merge for you.

3- You branch launchpad and update the utilities/sourcedeps.conf file to use 
the new loggerhead revision. Again push that branch for Launchpad and propose 
a merge.

4- It will be approved / merged for you.

5- This will be automatically deployed to qastaging, where you can QA it and 
make sure that it's actually working. Once that's done, it will be deployed by 
the LOSA at the next nodowntime deployment.

Let me know if you hit any snags with that process.

Cheers

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.