[LLVMdev] LLVM 3.4 stable releases

[Tom Stellard]

On Wed, Jan 22, 2014 at 09:26:49AM +0000, Renato Golin wrote:
> On 22 January 2014 08:57, Chandler Carruth <chandlerc at google.com> wrote:
> 
> > I don't think there is any need to rebase or send merge requests etc...
> > They'll apply cleanly, or I can manually merge them if need be. The
> > question is not how to merge them but *if* we should merge them, and if
> > someone will create tags / release numbers to track this.
> >
> 
> That's what I meant by "merge request", not if they *would* apply, but if
> they *should* be applied. ;)
> 
> It wasn't clear from my first email, I apologise, but I'm trying to come up
> with a process where we can easily detect, either now and later if you
> search the list, which patches are being proposed for back-porting. Today,
> we use "[PATCH]" for trunk, maybe we should have something like "[3.4.1]"
> or "[PATCH 3.4.1]" for the back-ports.
> 

What have for the Mesa project is a -stable list that we cc on all patches
that are candidates for the stable branch.  This is really easy to do with git
since you can add the CC: mesa-stable annotation to the commit and it is
automatically sent to the stable list when you use git send-email.  Also,
since the CC: annotation is in the commit message when it is committed to
master you can have a script auto-cherry pick all the stable patches to
the stable branch.

For LLVM, we could set up a stable branch and cc that on all stable patch
candidates.  This would make it easier for multiple people to track which
patches are being proposed for stable.  Though, this is probably the
equivalent of what Renato suggested, since people could just as easily
setup mail filters for the [PATCH 3.4.1] tag.

In addition, I think it would be nice to do what Mesa does and add a standard
annotation in the commit message for stable candidates.  Something like:
NOTE: This is a candidate for the 3.4 branch so we could partially

This would help automate the backporting process and make the release manager's
life much easier.

-Tom 
> The current release process is a bit confused in that we don't have a clear
> idea of which patches are being applied to each release candidate, because
> they're all spread out in the list without a clear identification, normally
> just copying the release manager, or waiting for him/her to pick it up from
> the discussion. I'd like to reduce this overhead by having clear semantics,
> so that the release manager could just filter for a specific pattern and be
> sure to have caught all back-port patches.
> 
> That'd also make it easier to write the change log, just by filtering
> emails on a mailing list.
> 
> Makes sense?
> 
> cheers,
> --renato