[LLVMdev] RFC: Bug fix releases for 3.3 and beyond

[Arnaud A. de Grandmaison]

That's a great idea and I would definitely like to participate to this effort.

I am maintaining several out-of-tree backends for Parrot, and this is 
essentially what I do : base the backends on the current official release, 
apply some upstream bug fixes or upstream bug fixes until I can rebase to the 
next release. 

Teaming up for this effort would be great for those developing externally to 
the tree.

I am not sure if we want to make point releases, and how we can ensure quality 
as this requires man power to test all variants. On the other hand, 
maintaining a branch with only "safe" (?) patches is definitely useful.

Cheers,
--
Arnaud A. de Grandmaison

On Tuesday 02 April 2013 11:29:00 Tom Stellard wrote:
> On Tue, Apr 02, 2013 at 09:59:39AM -0700, Chris Lattner wrote:
> > On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote:
> > > I would really like to see the LLVM project start to make official bug
> > > fix
> > > releases (e.g. 3.3.1, 3.3.2, etc.).  I think that this would be useful
> > > for a lot of the users of LLVM, especially projects that use LLVM as a
> > > library. I am willing to help maintain bug fix releases, and I'm
> > > wondering if this is something that the LLVM project would officially
> > > support with a stable SVN branch and by hosting the official stable
> > > tarball releases.> 
> > This would be really useful, and definitely welcome.  The major thing that
> > has historically prevented it from happening is manpower.  We have enough
> > difficulty as it is pulling together the official major releases.
> > 
> > However, if someone was interested in being the "update release manager"
> > and was willing to do the work to organize and qualify it, it could
> > definitely happen.  Tom, are you personally interested in doing this?
> Yes, I would be willing to be the "update release manager".
> 
> -Tom
> 
> > > I realize that maintaining stable branches is a lot of work, so I would
> > > like to come up with a procedure that makes maintaining these branches
> > > as easy as possible.  Here is a rough idea of what I had in
> > > mind, but please suggest alternatives if you know of a better way:
> > > 
> > > 1. Developer fixes a bug or makes a change that he/she thinks would make
> > > a good candidate for the stable branch.  Commits would require approval
> > > from the Code Owner in order to be backported to stable.
> > > 
> > > 2a. When the developer commits that change, he/she adds to the end of
> > > the
> > > commit message something like:
> > > 
> > > Note: This is a candidate for the stable branch
> > > 
> > > 2b. Alternatively, if a user discovers a bug in a stable release that
> > > has
> > > been fixed in ToT, he/she could request to have the fix backported.
> > > 
> > > 3. The developer would be encouraged, but not required to cherry-pick
> > > the
> > > commit to the stable branch.  The stable maintainer would periodically
> > > search the commit logs and cherry-pick any commits that had been missed,
> > > consulting with the author of the commit in the case of a difficult
> > > merge conflict.
> > > 
> > > 4. After some interval of time, the stable maintainer would announce
> > > plans for a stable release and testing would begin.
> > > 
> > > What does everyone think?  Would something like this be doable?
> > > 
> > > Thanks,
> > > Tom
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev