<div dir="ltr"><div><div><div>Like Bill said, would prefer if we take only bug fixes excluding the enhancement/feature change, <br></div><br></div>Developer who fixes the bug are most likely the best person to back port it to a release branch. <br>
<br></div>How do we decide when to release bug fix release? is it by the number of bug fixes or user request or fixed time?<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 6:21 AM, Bill Wendling <span dir="ltr"><<a href="mailto:wendling@apple.com" target="_blank">wendling@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

<span class="HOEnZb"><font color="#888888"><br>
-bw<br>
</font></span><div class="im HOEnZb"><br>
On Apr 2, 2013, at 2:10 PM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote:<br>
<br>
</div><div class="HOEnZb"><div class="h5">> On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote:<br>
>> On Apr 2, 2013, at 9:51 AM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> I would really like to see the LLVM project start to make official bug fix<br>
>>> releases (e.g. 3.3.1, 3.3.2, etc.).  I think that this would be useful for a<br>
>>> lot of the users of LLVM, especially projects that use LLVM as a library.<br>
>>> I am willing to help maintain bug fix releases, and I'm wondering if<br>
>>> this is something that the LLVM project would officially support with<br>
>>> a stable SVN branch and by hosting the official stable tarball releases.<br>
>>><br>
>>> I realize that maintaining stable branches is a lot of work, so I would<br>
>>> like to come up with a procedure that makes maintaining these branches<br>
>>> as easy as possible.  Here is a rough idea of what I had in<br>
>>> mind, but please suggest alternatives if you know of a better way:<br>
>>><br>
>>> 1. Developer fixes a bug or makes a change that he/she thinks would make<br>
>>> a good candidate for the stable branch.  Commits would require approval<br>
>>> from the Code Owner in order to be backported to stable.<br>
>>><br>
>>> 2a. When the developer commits that change, he/she adds to the end of the<br>
>>> commit message something like:<br>
>>><br>
>>> Note: This is a candidate for the stable branch<br>
>>><br>
>>> 2b. Alternatively, if a user discovers a bug in a stable release that has<br>
>>> been fixed in ToT, he/she could request to have the fix backported.<br>
>>><br>
>>> 3. The developer would be encouraged, but not required to cherry-pick the<br>
>>> commit to the stable branch.  The stable maintainer would periodically<br>
>>> search the commit logs and cherry-pick any commits that had been missed,<br>
>>> consulting with the author of the commit in the case of a difficult<br>
>>> merge conflict.<br>
>>><br>
>>> 4. After some interval of time, the stable maintainer would announce<br>
>>> plans for a stable release and testing would begin.<br>
>>><br>
>>> What does everyone think?  Would something like this be doable?<br>
>>><br>
>> 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.<br>
>><br>
>> 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.<br>

>><br>
><br>
> I was thinking for shared code it would be strictly bug fix only, but<br>
> maybe things like additional C API implementations or standalone passes<br>
> might be OK too assuming there is interest.<br>
><br>
> However, for target specific code, I think backend code owners should<br>
> have a little more leeway as far as what gets accepted.  For the<br>
> R600 backend I can see a situation where I may want to backport a new<br>
> feature or something else, so it would be nice to have a little more<br>
> flexibility and maybe other backend owners would want to have this<br>
> option as well.<br>
>> 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. :-)<br>

>><br>
><br>
> I understand.  I think if there is a patch that is too difficult for the<br>
> release maintainer to backport he/she should be able to go to the author<br>
> and request help.  If the author or some other party doesn't care enough<br>
> about the fix to help backport it, then it probably isn't important<br>
> enough to go to stable.<br>
><br>
>> 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?<br>
>><br>
><br>
> This is hard to say, but probably as required.<br>
><br>
>> 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?<br>

>><br>
><br>
> What is it about testing for releases that takes a month to complete?<br>
> Is it just coordinating with all the interested parties and making sure<br>
> they are happy with the state of the code?<br>
><br>
> -Tom<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Warm Regards<br>--Dev<br>OpenPegasus Developer<br>"It's Always better to try and fail instead of not doing/trying anything"<br>
</div>