[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk <wd@denx.de>]

In message <20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com> you wrote:
>
> Other people (Linus, for example) do not. I guess I'll just have to use
> different workflows for my u-boot and Linux work then...but I'm not
> quite done arguing yet ;-)

I appreciate your comments, really. I don't claim to be  perfect,  on
contrary  -  git is still new to me and I'm trying to find my way. If
it turns out that my ideas are  wong,  or  that  following  my  style
imposes  a  high  and  avoidable  burden to many others I will try to
adapt.

> But the stuff that has been collected may be in completely different
> states of development. Some patches may have pending review comments
> (which showed up after they were committed to the repository.) Some
> patches may need more testing (which they are much more likely to get
> after they have been committed to the repository.)
> 
> When the merge window comes up, the custodian should submit a merge
> request for all the patches that are considered complete and fully
> tested, and this usually involves cherry-picking patches into a freshly
> created branch, making the history non-linear.

I agree, except that my idea would be not to use  a  freshly  created
branch, but master.

> Also, if a bug shows up during testing, it should be folded into the
> original patch before it's merged upstream, or it will break "git
> bisect". This is just not possible if you only want to pull from a
> linear master branch.

When the custodian's repo continues to use  the  master  branch,  and
checks in a commit to fix the bug there, git-bisect should still work
fine.  The difference is that there will be not a single commit for a
"perfect", bug-free patch, but a buggy one plus a fix for the bug.

> How about you do those out-of-band pulls from the master branch (which
> is not to be rebased and may contain stuff that requires more testing)
> and only pull into mainline from the branch specified by the custodian?

I can do this if really needed, but  I  see  trouble  ahead.  I  know
myself.  I  will  see  a  pull  request for repo XXX and pull without
specifying a branch. Only when I will reply to the message after  I'm
done  to  ACK  it  I  will  notice that somewhere near the end of the
message there is a note saying "please pull from  branch  YYY".  This
already happened, so I know what I'm talking about ;-)

> I have no problem with that. I just think that custodians should be
> allowed to specify a different branch than "master" when sending a pull
> request.

If really necessary I will have to adjust to this, but I'd rather
avoid it.

> If you only ever want to pull from the master branch, and the master
> branch can't be rebased, how are we supposed to rebase?

Consider merging into your master branch as the  first  step  of  the
pull  request  - this is the point where you give up control over the
patch. Assume I would pull the very same moment. How  do  you  rebase
after I have pulled from your branch?

> > I don't think that we are different types of users - maybe  from  the
> > kind  of  work  we  do,  but  I  don't  see  why we should access the
> > custodian's repository differently. Actually I think  it's  a  pretty
> > good idea if others test the very same code I will be pulling later.
> 
> Sure, but some patches may require more testing than others.

Agreed. Hold them in testing branches as long  as  testingis  needed.
When they are ready to be merged into mainline, they can go into your
master branch, too. And from there I willpick them up.

> > I think only "small" topic branches should be rebased - this  is  the
> > part of the custodian's work that is needed to clean up the stuff and
> > to  make it ready for mainline merge. The he prepares a branch for me
> > and ofr other users to pull from.
> 
> I think your argument is inconsistent. How is "preparing a branch for
> you to pull" any different from rebasing?

It means rebasing of your working branches so that  they  are  up  to
date  and  don't cause conflicts before merging them into your master
branch.

> I think you'll receive more well-tested code if you allow custodians to
> commit patches to "master" earlier. But this necessarily means either
> being allowed to rebase the "master" branch or using a different branch
> for merging (which only contains code that has spent a fair amount of
> time in the master branch.)

To me, your master branch is your "stable" code. Code that needs more
testing should use a different branch name. Especially  if  you  have
different pots on the fire at the same time.

> IOW, one branch is for stuff that is ready to merge, the other is for
> the same _plus_ stuff that needs testing. I think using "master" for

You may want several independet "testing"  branches,  not  only  one.
master  seems not the best choice to me. I think we should use master
== stable.

> the latter will give the to-be-tested code much more exposure before it
> hits mainline, and that's IMO a good thing.

I understand your position, too. As mentioned above,  I  don't  claim
that my suggestion is perfect or optimal. I developed my own style of
working, others developed theirs. This discussion helps to figure out
how to make co-operation easier. Thanks!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I often quote myself; it adds spice to my conversation.  - G. B. Shaw