drizzle-merge team mailing list archive

[Lee Bieber <lee.bieber@xxxxxxxxxxxxx>]

I'm OK with most of this, I found it very confusing when you stepped in 
to help yesterday when I had to step away for a few minutes. I think its 
better to let one person play through. We should make sure that when we 
take on a merge we are committed to seeing it all the way through (my 
fault for having to step away).

But something is still not in sync. We shouldn't be seeing "n versions 
removed" messages from bzr when we push to build, staging or trunk. Also 
when I tried to pull from build/staging/trunk to my local branches this 
morning I got the dreaded "these branches have diverged" message. For 
safety sake I just started over fresh.

Here is a short summary of what we have documented on the wiki page - 
http://drizzle.org/wiki/Merging_Code   Please let me know if there is 
something here that is out of step in this process:

Build

   * bzr pull to make sure you are in sync
   * bzr merge <branches>
   * bzr commit
   * build and test
   * bzr push lp:drizzle/build

Staging

   * bzr pull to make sure you are in sync
   * bzr merge lp:drizzle/build
   * bzr commit
   * build and test
   * bzr push lp:drizzle/staging

Trunk

   * bzr pull to make sure you are in sync
   * bzr merge lp:drizzle/staging
   * bzr commit
   * build and test
   * bzr push lp:drizzle


On 8/5/10 10:54 PM, Brian Aker wrote:
> Hi!
>
> I thought I would explain a few more bits about merges.
>
> Lets say you have patches  23,24,25 in your local tree. Just push them to build. As long as none of them fail you are ready for staging.
>
> For staging I typically do a rollup of the three. So they will all become "23" with subrevision numbers (if you are ever worried that the rollup to staging has something that has not full gone through build, read the comments for uniqueness). The valgrind report should always be the indicator of whether or not something should move to staging (ie you can look at it and see if the latest passed or not).
>
> Once you have a rollup in "staging" you can push another set to build. Are there any issues with this?
>
> If staging fails you will have to over write anything you pushed after the rollup you pushed to staging. So you risk doing wasted work, but normally it is not a lot of wasted work.
>
> Is there anything that shouldn't be rolled up?
>
> Yes. If you have a major patch, something that touches a lot of files (lets call it 10+ ), unless it is just a simple "rename" patch, you should probably run it through the system by itself. I would also recommend that for the most part if you have a stack of  Stewart's patches that are just for the embedded engine, I would just put them in one merge.
>
> Should you ever use the build tree to fix a patch? IE build is broken and you want to push a "fix" for it. I would try to keep this to a minimum. For instance it is ok if it is a build related item. Valgrind/etc should probably be fixed in local trees. I've made the mistake plenty of times of trying to fix in build, it typically does not work.
>
> What about helping someone out?
>
> I think it would be nice if others could promote it (we all go out to eat, have other things to do, etc...). My only concern is  that this could be confusing. I've felt comfortable sometimes doing this in the last week, and I know that I have sometimes not. I am also aware that it can make someone feel "well, they were going to do it...". So I would love to hear other people's thoughts on it. Personally I like to see stuff moving through as quickly as possible, but there is a balance in this as well.
>
> Thoughts?
>
> Cheers,
> 	-Brian
>
>
> _______________________________________________
> Mailing list:https://launchpad.net/~drizzle-merge
> Post to     :drizzle-merge@xxxxxxxxxxxxxxxxxxx
> Unsubscribe :https://launchpad.net/~drizzle-merge
> More help   :https://help.launchpad.net/ListHelp
>    


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.