xen/tip.git and how it should function?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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?