[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen]

On Tue, 22 Jan 2008 14:45:48 +0100
Wolfgang Denk <wd at denx.de> wrote:

> In message <20080122105016.313d8f88 at dhcp-252-066.norway.atmel.com> you wrote:
> >
> > > Are you sure that is a good idea? Note that I (and probably others)
> > > will be pulling from that branch, and not only once!
> > 
> > That depends on whether or not you want your commit history filled with
> > "merge with upstream/master" crap or not.
> 
> ...which in turn depends on whether  or  not  you  consider  a  merge
> commit as crap or not. IMHO it's sometimes valuable information about
> the history of a project, but YMMV.

So you _do_ want that crap in the commit history ;-)

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 ;-)

> My point is a different one, and it seems I never explicitly stated it
> before:
> 
> My idea of a custodian repository is that it  is  more  than  just  a
> working  tool  for  collecting  patches and preparing these for merge
> into  mainline.  My  idea  is  instea  that  these  are  pretty  much
> independent  incarnations  of  U-Boot source trees which users (note:
> users, not only developers) with  specific  needs  or  interests  can
> refer to.
> 
> For example, in my set of mind somebody interested in the latest 85xx
> code would clone the 85xx custodian  repository,  expecting  that  he
> finds  there  the  most  current  code for this family of processors.
> Probably he will never sync himself  against  mainline,  but  instead
> continue update (pull) from the 85xx custodian repository.
> 
> That means, that my idea is that it is the custodian's responsibility
> to  provide  a  permanently  accessable,  consistent  view   of   his
> repository  to  users.  When  he  collects  patches,  he will - after
> sufficient review and testing - decide that these are good enough  to
> go  into  his  repository. And at certain points we will pull all the
> stuff that has been collected there into mainline.

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.

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.

> > You should only pull when explicitly requested to do so. In that case,
> 
> Actually I fetch from all custodian repos quite frequently. But I do
> only pull (merge into mainline) when I'm explicitely told.

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?

> But note that my idea  is  that  other  users  may  have  cloned  the
> custodian  repository,  and  continue  to  pull  from  it.  For their
> convenience (and my own) I want to have the current code collected in
> the master branch, and I think we agree that the master  branch  must
> not be rebased.

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 there are conflicting changes and the merge needs manual
> > intervention, you abort the merge and tell the one sending the pull
> > request that it didn't merge cleanly, please rebase.
> 
> Right - but this does not depend on how the custodian repos are set up
> or which branch I'm pulling from.

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?

> > >        way that will cause problems for anyone who already has a copy
> > >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >        of the branch in their repository and tries to pull updates
> > >        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >        from you. You should understand the implications of using git
> > >        ^^^^^^^^^
> > >        rebase on a repository that you share.
> > 
> > And that is, IMO, exactly why you shouldn't be pulling from the master
> > branch in the first place. People who pull regularly to test stuff that
> > is in progress will run into this problem, and they are most likely to
> > pull the master branch because that's the default.
> 
> People pulling the master branch have (IMHO) the right  to  expect  a
> consisten  history.  It is the custodians responsibility not to merge
> stuff into the master branch that causes conflicts.

Agreed.

> > There are two different kinds of users involved here: You (and other
> > maintainers that are "upstream" from someone), and regular users who
> > want to test stuff. Upstream maintainers should receive a clean
> 
> 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.

> > history, i.e. from a branch that is frequently rebased. At the same
> 
> 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?

> > So we need (at least) two different branches that are maintained in
> > different ways, and I think it's easier to tell you, Wolfgang and other
> > upstream maintainers, to pull from a non-master branch than to tell
> > everyone else in the world.
> 
> I still fail to see why separate branches would be  needed.  I  think
> using  the  same  one  makes more sense, as it allows me to pull from
> tested code.

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.)

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

Haavard