<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 12:51 PM, Tom Stellard <span dir="ltr"><<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div> </div><div style>The largest barrier that I see, which nobody seems to have mentioned, is the community culture. I think it is awesome that you are willing to put time into this (and I see at least one other would be too!), but in one way or another your proposal has an impact on *every* developer of the project, either </div>
<div style><br></div><div style>(2a) Through the developer having to reflect before each commit and make the risk/benefit evaluation for whether it is viable for the stable branch or </div><div style>(2b) Being willing to put in some nontrivial amount of time to backport (at least one ~full rebuild, since they will at least have to check out and build the tip of the stable branch in order to backport).</div>
<div style><br></div><div style>Do you think the community will be willing to take on this burden? It seems like a bit of a culture shift, and one that is not very aligned with out "don't look backwards" mantra that fuels our backward compatibility policy. Are there other things we could request from every developer that would be a better use of their time than a stable branch? e.g. would that time be better spent documenting or writing tests? That's not so far-fetched: consider a community culture shift where in response to mailing list threads ("user requests", quite similar to 2b) developers were encouraged to document their answer. Would that be a better use of time? Or to consciously reflect before each commit "does this require adding new documentation?" (similar to 2a) </div>
<div style><br></div><div style>Also, it's not clear that we have the infrastructure to test these dot releases on all our supported platforms. IMHO, without that, it's hard to have much confidence in the dot release, and I wouldn't want to put out "LLVM 3.2.1, tested on Linux only". </div>
<div style><br></div><div style>-- Sean Silva</div></div><br></div></div>