launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Tue, Nov 9, 2010 at 2:12 AM, Henning Eggers
<henning.eggers@xxxxxxxxxxxxx> wrote:
> I have been thinking. Since we now have continuous roll-outs for code changes,
> the release really is mainly about rolling out database changes. I think the
> process should reflect that and I think that we can get away without closing
> pqm for devel at all. It looks like this is similar to your plan since that
> does not mention locking down db-devel.

It is similar yes. I'm going to pick the key points out - happy to
discuss more, but I wanted to get an answer to you in our time zone
overlap..

>  4) When db-stable has settled down, pick the release revision of db-stable
> and merge that into production and into devel/stable.

We're not using 'production' anymore.


>  7) Re-enable continuous roll-outs.

A 6b) would be needed - qa up *past* the merge point of db-stable nto devel.
*and* we'd only merge the chosen rev of db-stable, not time.

>> This will have the following impact:
>>  - we'll see a clean db upgrade happen with all the db patches
>
> Hm, I don't know what that means exactly.

Merging db-stable to devel will cause qa-staging to run the db upgrade
process, which we often have to reset staging to do - but qastaging is
ready to test at any point.


>>  - revnos in production will not jump around
>
> Can we not avoid that by simply merging db-stable into production instead of
> replacing it (like we did until now, I think)?

db-stable has a revno of < 10K; devel has a revno of > 11K : they will
jump around in your proposal.

> I wanted to announce the PQM closure to the developers today but it would have
> to be different if we adopt any of these changes.
>
> Thoughts? What did I miss?

Your proposal also changes the branch we focus on - devel, to
db-devel, then back to devel. I'd rather use a merge to bring pending
changings *into devel* and focus on that branch.

-Rob