New release process for 1.8 (READ THIS)

[Peter Hutterer]

On Thu, Oct 01, 2009 at 08:04:08AM -0700, Daniel Stone wrote:
> On Thu, Oct 01, 2009 at 01:36:39AM -0700, Jeremy Huddleston wrote:
> > On Sep 30, 2009, at 19:43, Peter Hutterer wrote:
> >> Question: tree on people.fdo or branch on the main repo?
> >> branches on the main repo have the advantage of the commit list which
> >> provides some chance for patch review.
> >
> > If we go for a separate tree, would someone be kind enough to explain  
> > how to set that up and best practices for merging changes from master on 
> > the main repo into our own tree (when to merge, when to rebase)?  I got 
> > the sh*t knocked out of me figuring out git the first time, and I've had 
> > the pleasure of not having to deal with multiple repos yet.  Plus, I've 
> > heard conflicting suggestions on when to rebase and when to merge.  From 
> > what I see, merge is correct for anything in the wild, but rebase makes 
> > your patchset cleaner... so should we be rebaseing our trees against 
> > master or merging?
> 
> In general, a separate tree is practically identical to a branch, at
> least in terms of how you use it for commits/etc.  As for rebasing vs.
> merging, you do a rebase when the history information you get from the
> merge is not really relevant.  Note that this changes your repo, so if
> you're doing it on published branches, then you have to make sure the
> people using it and/or developing against it know.

The simple rule is - anything that has been published must not be rebased*.
Anything that's local only should be rebased, it gives you a nicer history.

I'll write up the workflows for testers, developers and maintainers next
week on the wiki. Having it in an email here is counterproductive since that
may become the "authoritative" source for how to do it ignoring follow-ups
that correct me where I'm wrong.

Cheers,
  Peter
  
* Exception: If you want a real testing branch though you can have a
  rebasing devel branch, as long as you let your users know that pulling
  won't be fast-forward. So you push to that branch, let users test and
  then cherry-pick the tested patches to the real branch.