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

Tue Apr 2 22:03:34 PDT 2013

Like Bill said, would prefer if we take only bug fixes excluding the
enhancement/feature change,

Developer who fixes the bug are most likely the best person to back port it
to a release branch.

How do we decide when to release bug fix release? is it by the number of
bug fixes or user request or fixed time?

On Wed, Apr 3, 2013 at 6:21 AM, Bill Wendling <wendling at apple.com> wrote:

> For the record, I'm not opposed to this. I'm mostly playing devil's
> advocate. But I do feel that these are issues that need to be thought out
> before we continue.
>
> -bw
>
> On Apr 2, 2013, at 2:10 PM, Tom Stellard <tom at stellard.net> wrote:
>
> > On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote:
> >> On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote:
> >>
> >>> Hi,
> >>>
> >>> 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.
> >>>
> >>> 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?
> >>>
> >> As Chris said, the only thing preventing this is manpower. But if there
> are people ready and willing to do this, then I don't see it as a Bad Thing.
> >>
> >> My first comment is that these should be strictly bug fix releases. So
> your (1) above wouldn't include changes other than bug fixes. There would
> need to be a hierarchy for bugs. The reason is that *any* change to the
> stable branch inherently carries risk. So for instance, a bug that's a
> crasher, but would affect only a small number of people may not be worthy
> of inclusion into a dot-release. Etc.
> >>
> >
> > I was thinking for shared code it would be strictly bug fix only, but
> > maybe things like additional C API implementations or standalone passes
> > might be OK too assuming there is interest.
> >
> > However, for target specific code, I think backend code owners should
> > have a little more leeway as far as what gets accepted.  For the
> > R600 backend I can see a situation where I may want to backport a new
> > feature or something else, so it would be nice to have a little more
> > flexibility and maybe other backend owners would want to have this
> > option as well.
> >> My second comment is that top-of-tree moves very fast. This can make
> changes hard to back-port to a stable branch that may be months old. You
> are stuck having to either do it yourself, or begging the original author
> to back-port the fix. :-)
> >>
> >
> > I understand.  I think if there is a patch that is too difficult for the
> > release maintainer to backport he/she should be able to go to the author
> > and request help.  If the author or some other party doesn't care enough
> > about the fix to help backport it, then it probably isn't important
> > enough to go to stable.
> >
> >> How frequently do you expect to do a dot-release? Our major release
> schedule is roughly every 6 months. Do you think bimonthly would be too
> many? or would you do it only when enough changes require it?
> >>
> >
> > This is hard to say, but probably as required.
> >
> >> Finally, there is testing to consider. Obviously, full testing would be
> too rough on the community; people simply don't have enough time to spend a
> full month testing a dot-release. What are you thoughts on how testing
> would proceed?
> >>
> >
> > What is it about testing for releases that takes a month to complete?
> > Is it just coordinating with all the interested parties and making sure
> > they are happy with the state of the code?
> >
> > -Tom
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Warm Regards
--Dev
OpenPegasus Developer
"It's Always better to try and fail instead of not doing/trying anything"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/bfd7f28a/attachment.html>