[U-Boot] U-Boot git usage model

[Scott Wood <scottwood@freescale.com>]

On 10/11/2012 12:27:57 PM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/11/12 10:16, Scott Wood wrote:
> > On 10/11/2012 11:38:00 AM, Tom Rini wrote:
> >> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
> >>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren
> >>> wrote:
> >> [snip]
> >>>> The problem with rebasing when pulling is that git commit
> >>>> IDs change, so it's much more difficult to determine when a
> >>>> commit is merged into a parent tree; one has to search by
> >>>> commit subject rather than just executing e.g. git branch -a
> >>>> --contains XXX. I thought Albert just agreed to use merges
> >>>> rather than rebases for u-boot-arm for this and perhaps
> >>>> other reasons.
> >>>
> >>> The short answer is that right now, u-boot/next follows the
> >>> linux-next model and we rebase as needed.
> >>
> >> I'm going to reply to myself, in hopes of clearing things up.
> >> We don't follow the linux-next model, really, I miss-spoke.
> >>
> >> History is important.  But so is getting the amount of process
> >> for the size of the project.  The other thing is that we're
> >> doing simultaneous development for both the current release and
> >> the next release.
> >>
> >> So for the master branch of the master repo, it must never
> >> rebase.  And as Wolfgang encourages users to use the custodian
> >> repository of mainline isn't quite up to what they need,
> >> custodian repositories must also keep their master branch
> >> un-rebased as much as humanly possible (my rule of thumb would
> >> be once it's been in the wild for a few days, it's too late).
> >>
> >> The next branch however can be rebased, as needed.
> >
> > Why is the next branch any different?  Users and custodians will
> > both be affected by any rebase, just as if a master branch gets
> > rebased.  This hybrid of the Linux approach and what was described
> > in this thread as the U-Boot approach is worse than consistently
> > doing one or the other IMHO.
> 
> The number of people working on next should be small and manageable.

More people likely use next than some custodian branches, and those are  
supposed to be rebase-free...

Wouldn't anyone developing code for the next merge window be working on  
next,
at least when it's not out of date?

> But, yes, it bears more thinking if we want the next branch open for
> longer than it has historically been, if we want that.  And we have at
> least historically been saying that next can and will be rebased.

IMHO it would be nice for the next branch to open immediately after the  
merge window closes, and be kept up to date except during the merge  
window.  Historically the next branch has opened when someone requests  
a pull into it, but how do I make a sane pull request when the next  
branch has been untouched since the last release?

-Scott