Hi, A few months ago, I mentioned I was interested in helping to make dot releases for LLVM 3.3. Now that 3.3 has been released, I would like to kick off the process of collecting bug fixes and merging them into the 3.3 branch. I reviewed the previous discussion about dot releases: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/060821.html and I've come up with the following dot release 'rules': + Dot releases will follow the same procedure as major releases, which means stable patches must be approved by the appropriate code owner and that dot releases will have the same testing and qualification requirements. + No regressions. If a patch to the stable branch introduces a regression that cannot be fixed, it will be reverted. + Participation from developers is optional. If developers don't have time to help with issues in the stable branch, they do not have to. I'm sure we'll need to amend or add to these rules as we work through the dot release process, but I think this list is a good starting point. So, with these rules in mind, I would like to volunteer for to be the release manager for the 3.3 dot releases, which means I would be responsible for overseeing the release process and also making commits the 3.3 branch. I'll just throw it out there that we should aim for a dot release in two months. I don't want to set anything in stone, though, because I think that we may want to adjust this depending on how much activity there is in the stable branch. What I'm asking for now from the LLVM community now is: + Approval to commit patches to the 3.3 stable branch (This is really a question for Chris). + Individual contributors who are interested in helping with dot releases in any way. + Contacts from projects that use LLVM and are interested in coordinating their releases with LLVM dot releases. I'm looking forward to working with the community and making LLVM dot releases a success! Thanks in advance to everyone for your help. - Tom
Hi Tom, We, at Parrot, are using LLVM/Clang for our various home-made cpus / dsps. This is done on private backends, but I am interested in participating to the dot releases, as this is essentially what I am doing internally : select patches to fix bugs to the current release --- beside developing the backends :) FWIW, I also participated to the 3.3 release. Cheers, -- Arnaud A. de Grandmaison On Monday 24 June 2013 09:08:10 you wrote:> Hi, > > A few months ago, I mentioned I was interested in helping to make dot > releases for LLVM 3.3. Now that 3.3 has been released, I would like > to kick off the process of collecting bug fixes and merging them into the > 3.3 branch. > > I reviewed the previous discussion about dot releases: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/060821.html > and I've come up with the following dot release 'rules': > > + Dot releases will follow the same procedure as major releases, which > means stable patches must be approved by the appropriate code owner and > that dot releases will have the same testing and qualification > requirements. > > + No regressions. If a patch to the stable branch introduces a regression > that cannot be fixed, it will be reverted. > > + Participation from developers is optional. If developers don't have > time to help with issues in the stable branch, they do not have to. > > I'm sure we'll need to amend or add to these rules as we work through the > dot release process, but I think this list is a good starting point. > So, with these rules in mind, I would like to volunteer for to be the > release manager for the 3.3 dot releases, which means I would be > responsible for overseeing the release process and also making commits the > 3.3 branch. > > I'll just throw it out there that we should aim for a dot release in two > months. I don't want to set anything in stone, though, because I think > that we may want to adjust this depending on how much activity there is > in the stable branch. > > What I'm asking for now from the LLVM community now is: > > + Approval to commit patches to the 3.3 stable branch (This is really > a question for Chris). > > + Individual contributors who are interested in helping with dot > releases in any way. > > + Contacts from projects that use LLVM and are interested in > coordinating their releases with LLVM dot releases. > > I'm looking forward to working with the community and making LLVM dot > releases a success! Thanks in advance to everyone for your help. > > - Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Arnaud A. de Grandmaison
On Jun 24, 2013, at 9:08 AM, Tom Stellard <tom at stellard.net> wrote:> What I'm asking for now from the LLVM community now is: > > + Approval to commit patches to the 3.3 stable branch (This is really > a question for Chris).Go for it. -Chris> > + Individual contributors who are interested in helping with dot > releases in any way. > > + Contacts from projects that use LLVM and are interested in > coordinating their releases with LLVM dot releases. > > I'm looking forward to working with the community and making LLVM dot > releases a success! Thanks in advance to everyone for your help. >
On 25/06/13 00:08, Tom Stellard wrote:> What I'm asking for now from the LLVM community now is: > > + Individual contributors who are interested in helping with dot > releases in any way.I'm happy to run the regression tests and build binaries, as I did for the 3.3 release. I can do this for 32 and 64bit builds on Ubuntu 13.04. Ben
On 24 June 2013 17:08, Tom Stellard <tom at stellard.net> wrote:> + Participation from developers is optional. If developers don't have > time to help with issues in the stable branch, they do not have to. >This may be very hard on the interested parties in the long term. I agree that we should not force the dot-release on everyone as of now, but if it becomes an accepted policy, I think people should start thinking about it more often. That doesn't mean people will have to have several trees to test on, but we'd have to have build-bots on the stable release covering at least the basics, so to make the process more automatic and painless to all. + Individual contributors who are interested in helping with dot> releases in any way. >I can always re-run the release tests on ARM+Linux, no problems. Would be great if you could change the test-release script to account for that change beforehand, so that release testers can do that seamlessly. Currently, we have "rcN" and "final", we should move to "rcN.M" and "dotN" or something similar, to account for the dot releases... So: rc0.1 -> rc0.2 -> rc0.3 -> dot0 -> rc1.1 -> ... -> dot1 -> ... So that, in the script, we chose: "-release 3.4 {-rc2.1 or -final}| and the script will checkout the correct tag of the correct branch. Of course, to not disrupt the current release process, "-rc1" would have to alias to "-rc0.1" and "-final" aliasing to "-dot0". cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130625/0decd957/attachment.html>
Hi Tom, On 24 Jun 2013, at 17:08, Tom Stellard <tom at stellard.net> wrote:> I've come up with the following dot release 'rules': > > + Dot releases will follow the same procedure as major releases, which > means stable patches must be approved by the appropriate code owner and > that dot releases will have the same testing and qualification requirements. > > + No regressions. If a patch to the stable branch introduces a regression > that cannot be fixed, it will be reverted. > > + Participation from developers is optional. If developers don't have > time to help with issues in the stable branch, they do not have to.What are the rules about API / ABI stability within the point releases? From our perspective downstream, it would be nice to have bug-fix incremental releases that were binary compatible, so that we could just pull them in and not worry about breaking anything. It would be okay to have things that were source compatible, but slightly less useful. It would be of no benefit to us if there are backwards-incompatible API changes in the point releases. David
On 25 June 2013 09:59, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> What are the rules about API / ABI stability within the point releases? > From our perspective downstream, it would be nice to have bug-fix > incremental releases that were binary compatible, so that we could just > pull them in and not worry about breaking anything. It would be okay to > have things that were source compatible, but slightly less useful. It > would be of no benefit to us if there are backwards-incompatible API > changes in the point releases. >This is a very sane requirement and I concur binary and API compatibility should be enforced. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130625/07f04bb0/attachment.html>
Will LLLVM dot releases include fixes for Clang as well? -- Regards, Konstantin
On Tue, Jun 25, 2013 at 09:11:17AM +0100, Renato Golin wrote:> On 24 June 2013 17:08, Tom Stellard <tom at stellard.net> wrote: > > > + Participation from developers is optional. If developers don't have > > time to help with issues in the stable branch, they do not have to. > > > > This may be very hard on the interested parties in the long term. I agree > that we should not force the dot-release on everyone as of now, but if it > becomes an accepted policy, I think people should start thinking about it > more often. > > That doesn't mean people will have to have several trees to test on, but > we'd have to have build-bots on the stable release covering at least the > basics, so to make the process more automatic and painless to all. > > > + Individual contributors who are interested in helping with dot > > releases in any way. > > > > I can always re-run the release tests on ARM+Linux, no problems. > > Would be great if you could change the test-release script to account for > that change beforehand, so that release testers can do that seamlessly. > > Currently, we have "rcN" and "final", we should move to "rcN.M" and "dotN" > or something similar, to account for the dot releases... So: > > rc0.1 -> rc0.2 -> rc0.3 -> dot0 -> rc1.1 -> ... -> dot1 -> ... > > So that, in the script, we chose: "-release 3.4 {-rc2.1 or -final}| and the > script will checkout the correct tag of the correct branch. >This sounds like a good idea to me, I can work on updating the script. -Tom> Of course, to not disrupt the current release process, "-rc1" would have to > alias to "-rc0.1" and "-final" aliasing to "-dot0". > > cheers, > --renato
On Tue, Jun 25, 2013 at 09:59:52AM +0100, David Chisnall wrote:> Hi Tom, > > On 24 Jun 2013, at 17:08, Tom Stellard <tom at stellard.net> wrote: > > > I've come up with the following dot release 'rules': > > > > + Dot releases will follow the same procedure as major releases, which > > means stable patches must be approved by the appropriate code owner and > > that dot releases will have the same testing and qualification requirements. > > > > + No regressions. If a patch to the stable branch introduces a regression > > that cannot be fixed, it will be reverted. > > > > + Participation from developers is optional. If developers don't have > > time to help with issues in the stable branch, they do not have to. > > What are the rules about API / ABI stability within the point releases? From our perspective downstream, it would be nice to have bug-fix incremental releases that were binary compatible, so that we could just pull them in and not worry about breaking anything. It would be okay to have things that were source compatible, but slightly less useful. It would be of no benefit to us if there are backwards-incompatible API changes in the point releases. >Definitely no API changes allowed. I think it makes sense to keep the ABI stable as well. My guess is most users would prefer this. -Tom