Re: rdma kernel tree

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]

On Thu, 2015-05-14 at 16:03 +0300, Or Gerlitz wrote:
> On 5/13/2015 6:27 PM, Doug Ledford wrote:
> > They will land at kernel.org when I know they won't change again (which
> > really means when I have the final kdoc patch and Ira's dependent
> > patches and everything there is merged properly).  For now, they are
> > present at the github repo as:
> >
> > mwang-v8
> > ira-cleanups
> > to-be-rebased/for-4.2 (which is nothing but a merge of the two above
> > branches)
> 
> Doug,
> 
> Developers whose work depends on other people can't chase multiple 
> branches.

Fair enough.  I'll still keep my various topic branches, but I'll also
keep a for-next tag that you can easily pull to always get the right
stuff.

>  And they need not wait for the maintainer to be 110% sure that 
> something is final. Our community is small enough to swallow rebases you 
> would do if at some point a patch for the next kernel is replaced, etc.

My reason for not rebasing anything that touches kernel.org is because
that was a specific request from Linus.  Other people might do it, but
I'm going to respect his wishes.  I agree with you that we have a small
enough community and the people are generally able to deal with rebases.
That's why I have my github repo too.  To further keep with Linus'
wishes, my branches on github that might rebase are clearly labeled as
such (although that won't be obvious pulling a tag, but that's the best
I can do).

> As others companies we have here internal review (Gerrit), build and 
> regression systems which are dependent on the open-source maintainers 
> trees/branches (for example, Dave Miller's net and net-next trees and 
> used to be also on Roland infiniband.git / for-next branch).  These 
> branches must be well known in location and name.
> 
> Lets find a way to get things in that direction, for everyone's benefit.

I'm fine with that.  What I'll propose is the following:

Kernel.org tree: never rebases, will use a topic branch per release, I
will coordinate tags on the different branches because Linus prefers to
pull from signed tags anyway.  So, for-linus tag will always be the
current code I wish Linus to pull, for-next will be the official next
tag and it won't rebase, it will only move forward.

github.com tree: will have my various topic branches (these will come
and go as code is taken, merged into mainline, and then branch deleted),
will have copies of the official k.o/ branches (which won't rebase), and
will have to-be-rebase/* branches where I pull things together until I
am happy with the overall branch and then I will move it over to k.o/*
and it will no longer rebase.  It will also contain the most recent
for-linus tag, and it will contain a for-next that.  The only special
thing about the tags is if the for-next tag on k.o and here don't match,
it means that this tag points to a branch that might be rebased and has
not been blessed as official yet.  Once the tags between the two repos
are identical again, you will know I've made the last rebase and moved
the branch to the official status.

So, under that scheme, your automated stuff can be pointed at k.o
for-next, or if it is able to deal with rebases (meaning that your
automated system blows away the last kernel and performs the merges all
over again each time it runs) then you could point it at github
for-next.  Is that acceptable?


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]