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

[Bill Wendling]

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