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? Thanks, Tom
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? -Chris> > 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
Tom Stellard <tom at stellard.net> writes:> 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.[snip]> What does everyone think? Would something like this be doable?As a LLVM library user I considered creating a bug fix branch and devoted some time to study how it would run. Unlike your proposal, my premise was to assume zero collaboration from the developers and the LLVM project infrastructure itself (just to cover the worst case.) It would run by just monitoring bugzilla and commit notifications in the mailing lists and cherry picking changes into a git repo hosted in Github. The goal was to monotonically increase the quality of the branch. I concluded that it is doable with about 10 hours/week, although there are some serious constraints. From the top of my head, in no particular order: 1. One must assume that the development branch will diverge fast on the "hot" areas, which are precisely those were most bugs tend to happen. So not all fixes could be imported. 2. The covered platforms might be limited (in my case, just x86/Linux/Windows and x86_64/Linux.) Unless you have the necessary machines or put too much trust on the bug fix author. 3. There would be cases where you cannot decide if a patch that fixes a bug jeopardizes the global quality of the branch, so when in doubt, those fixes should be ignored. This could be alleviated somewhat asking the opinion of the relevant developers but, as mentioned, I didn't count on them. 4. At some point, the development branch would be so far away that it would make little sense to keep maintaining the bug fix branch. In that regard, the lifetime of the bug fix branch would start with a Y.X release and end with a Y.(X+1) release, unless for the cases where applying a fix to a previous version would be a no-brainer. 5. There would be no bug fix releases. As mentioned, the bug fix branch quality must monotonically grow over time. The idea of a release implies "bug fixing the bug fixes", something you can not do unless the developers are working with you. And it doesn't make much sense when you work on a relatively short period (see point 4.) So in this point, it must be stressed that risky bug fixes should be held back or incorporated on special branches if they are important enough. There are other factors/ideas involved, such as semi-automatically detecting changes that touches areas modified by a previous bug fix (for examining them in detail), if completely ignoring the areas not specifically covered by the review process (see point 2), using a stage-based process where fixes advance on a series of "maturity level" branches, etc.
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 >
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. 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. :-) 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? 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? -bw
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: > > 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. > > 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. :-) > > 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? > > 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? > > -bwHello folks. I believe the best policy for maintenance release dates should be driven by the need to fix a critical bug. If you do a major release and a critical bug is found in the first few weeks, then a maintenance release should happen in that time frame. Maintenance releases are not scheduled by the calendar but by the needs of the users relating to known bugs. If you do a little research on the linux kernel maintenance releases, you'll see a clear pattern, where there are typically several patch releases in the first month, and the rate of patches exponentially declines rather quickly. I would expect the same of any complex code base. enjoy, Karen -- Karen Shaeffer Neuralscape, Mountain View, CA 94040
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
Sebastien DELDON-GNB
2013-Apr-03 08:07 UTC
[LLVMdev] RFC: Bug fix releases for 3.3 and beyond
Hi Tom, This is a great idea, we have ourselves back-ported fixes from trunk in LLVM 3.2 we are using. For stable release is it reasonable to count on a new BUG-fix release every two months for instance ? Seb> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Stellard > Sent: Tuesday, April 02, 2013 6:52 PM > To: LLVM Developers Mailing List > Subject: [LLVMdev] RFC: Bug fix releases for 3.3 and beyond > > 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? > > Thanks, > Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Devchandra L Meetei
2013-Apr-03 08:43 UTC
[LLVMdev] RFC: Bug fix releases for 3.3 and beyond
Hi Sebastian, every 2 months if we have atleast some number(decided) of fixes? Releasing a bug fix release with one/two fixes seems to be not worth the product release testing. On Wed, Apr 3, 2013 at 1:37 PM, Sebastien DELDON-GNB < sebastien.deldon at st.com> wrote:> Hi Tom, > > This is a great idea, we have ourselves back-ported fixes from trunk in > LLVM 3.2 we are using. > For stable release is it reasonable to count on a new BUG-fix release > every two months for instance ? > > Seb > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > On Behalf Of Tom Stellard > > Sent: Tuesday, April 02, 2013 6:52 PM > > To: LLVM Developers Mailing List > > Subject: [LLVMdev] RFC: Bug fix releases for 3.3 and beyond > > > > 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? > > > > 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 >-- 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/97518c93/attachment.html>
On Tue, Apr 2, 2013 at 12:51 PM, 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? >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 (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 (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). 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) 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". -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/18772250/attachment.html>
Sean Silva <silvas at purdue.edu> writes:> The largest barrier that I see, which nobody seems to have mentioned, is > the community culture.[snip] Well, the plan I described assumed "zero collaboration from the developers" for exactly the reasons you mentioned. IMO it is possible to bring a "maintenance branch" which is preferable to the development branch for those LLVM users searching for stability, without disturbing current development process. After all, you only need to make it a more attractive option than jumping into ToT tracking.> 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".If you cover a large fraction of the users, why not?
Krzysztof Parzyszek
2013-Apr-03 19:08 UTC
[LLVMdev] RFC: Bug fix releases for 3.3 and beyond
On 4/2/2013 11:51 AM, Tom Stellard 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.Does this really make sense with a 6 month release cycle for the main releases? Who are the customers who would be able to request a dot release? Each additional bugfix release carries a significant cost. Who is going to be investigating bugs in prior releases, especially if the problem can no longer be reproduced with the development branch? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Wed, Apr 03, 2013 at 02:08:42PM -0500, Krzysztof Parzyszek wrote:> On 4/2/2013 11:51 AM, Tom Stellard 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. > > Does this really make sense with a 6 month release cycle for the > main releases? Who are the customers who would be able to request a > dot release?I don't think the length of the release cycle really matters too much. The main point of having dot releases is so that projects that depend on LLVM can ship their own stable releases that are based on a stable version of LLVM. As it stands now projects either have to use a released version of LLVM and just accept whatever bugs come with it or they need to go back and update their own stable versions (which makes them not so stable) each time there is a new LLVM release.> Each additional bugfix release carries a significant cost. Who is > going to be investigating bugs in prior releases, especially if the > problem can no longer be reproduced with the development branch? >If someone cares enough about a bug, then they should be willing to spend the time investigating it. -Tom> -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Joerg Sonnenberger
2013-Apr-03 19:59 UTC
[LLVMdev] RFC: Bug fix releases for 3.3 and beyond
On Wed, Apr 03, 2013 at 02:08:42PM -0500, Krzysztof Parzyszek wrote:> On 4/2/2013 11:51 AM, Tom Stellard 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. > > Does this really make sense with a 6 month release cycle for the > main releases? Who are the customers who would be able to request a > dot release?Yes, it does. Consider miscompiles as an example.> Each additional bugfix release carries a significant cost. Who is > going to be investigating bugs in prior releases, especially if the > problem can no longer be reproduced with the development branch?Bugfix releases and maintainance of a release branch are somewhat separate issues. The former requires the latter, but not the other way around. Having a common base for cherry picking fixes would help e.g. FreeBSD (and NetBSD in the near future) a lot. Joerg
On Tue, Apr 02, 2013 at 09:51:49AM -0700, Tom Stellard 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.Others have commented on the benefits to FreeBSD and NetBSD with regard to the copy of clang and LLVM in the base system. I agree with those. I can see one issue for the ports collection. One of the problems we have right now is the need to maintain multiple versions of LLVM or clang in the tree to accommodate dependent software that hasn't been updated yet. I expect that the existence of stable branches will cause this to be more common as under-resourced projects skip releases. I think this is fine, but right now we can only install one version of clang/llvm at a time because they use conflicting paths. It would be really nice if LLVM and clang grew the ability to let different versions be installed at the same time. For gcc with install each version as gccXX so gcc46, g++46, etc and specify per-version directories to store all the libraries. The key bits of the ports make file (setting arguments to configure) are: SUFFIX= 46 TARGLIB= ${PREFIX}/lib/gcc${SUFFIX} LIBEXEC= ${PREFIX}/libexec/gcc${SUFFIX} CONFIGURE_ARG= --libdir=${TARGLIB} \ --libexecdir=${LIBEXEC} \ --program-suffix=${SUFFIX} \ --with-gxx-include-dir=${TARGLIB}/include/c++/ -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/968905f9/attachment.sig>