[Xen-devel] xen/tip.git and how it should function?

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Hey Stefano, Boris, David and everybody else.


I figured that having a one Linux tree for all the maintainers to put Xen 
related
patches would help with:
 - Testing
 - Logistics with patches overlapping
 - More eyes - hence easier to check something.
 - Easier to backport all Xen changes.

In the past the workflow I had was to create at a certain point (rc3-ish) a
'stable' branch where I would put the patches for the next release. For example
the next one would be called 'stable/for-linus-3.12'.

During the rc3->rc7 time patches would accumulate there. Everytime a patch is 
put
in, the branch is called merged in the #linux-next branch. This means that 
linux-next
will always contain the latest from Linus tree and the latest for the next 
release.

Then when we are two weeks before the merge window I tag it. I create a nice 
signed tag
called 'stable/for-linus-3.12-rc0-tag' where I do a writeup of all patches. 
That is
what Linus gets in his GIT PULL.

Once the merge window is completed and we find bugs, we pile them up in this 
branch
(stable/for-linus-3.12). New features are put in 'stable/for-linus-3.13' .. and 
so
on.


This worked great for me - as I only had two bins to put things in. Oh and of 
course
you cannot rebase either one of those trees.

And sometimes I created an 'devel/for-XXX-3.13' which could be rebased and 
deleted. But
it kept the 'unstable' patches that eventually would trickle to the 
stable/for-XXX-3.13.

With two maintainers, this should be easy enough - each maintainer can put his 
or her
patches in their local tree (or some git tree). Create a 
'stable/for-linus-3.12' and
do a git merge on his or her local tree, and push said 'stable/for-linus-3.12' 
up
to the tip tree.

Or just push them in #linux-next first to make sure they don't blow up.

Thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel