Hello everyone, There is still some time to go, but I would like to share my preliminary plan for 3.7. The idea is to keep us on the 6-month release cycle, which means: - Branch for 3.7 on 14 July 2015 - Release 3.7 end of August (absolutely no later than 4 September) I also have a few things I'd like to try this time: - Announce the first release candidate on llvm-announce to encourage more early testing. Last time many issues were raised late in the process. I'm sure that will happen this time too, but announcing the RC to a wider audience might help mitigate some of that. - Using CMake for the release binaries. I think I promised we'd do this for 3.7. I haven't actually started looking at this yet, but I'm still optimistic. - Provide a tarball with the docs and doxygen as part of the release. - PGP signatures on pre-built binaries: the person who builds the binary should sign it (unless you think this is too involved). - Not including Dragonegg in the release; it seems pretty unmaintaned by now. Please let me know what you think! Cheers, Hans
On Wed, 27 May 2015 at 01:01 Hans Wennborg <hans at chromium.org> wrote:> Hello everyone, > > There is still some time to go, but I would like to share my > preliminary plan for 3.7. > > The idea is to keep us on the 6-month release cycle, which means: > > - Branch for 3.7 on 14 July 2015 > - Release 3.7 end of August (absolutely no later than 4 September) > > I also have a few things I'd like to try this time: > > - Announce the first release candidate on llvm-announce to encourage > more early testing. Last time many issues were raised late in the > process. I'm sure that will happen this time too, but announcing the > RC to a wider audience might help mitigate some of that. > > - Using CMake for the release binaries. I think I promised we'd do > this for 3.7. I haven't actually started looking at this yet, but I'm > still optimistic. >I've been very slowly chipping away at issues that are holding back Debian packaging from using CMake. I've got a question about a small break in compatibility with autotools. Over at http://reviews.llvm.org/D10562, I have a patch up for review that adds a clang(1) man page to the Sphinx docs in clang/docs, and adds a CMake target for it. At the moment there is Makefile under clang/docs/tools that builds a man page using pod2man, but no CMake target. I'd like to remove cmake/docs/tools/Makefile, clang.pod and associated files. Packagers would need to build the man page using Sphinx, which is what is done for LLVM tools (llc, lli, etc.) at the moment. Even if using autotools, the man page can be built by invoking Makefile.sphinx directly. Does anyone object to this change happening before branching for 3.7? Cheers, Andrew - Provide a tarball with the docs and doxygen as part of the release.> > - PGP signatures on pre-built binaries: the person who builds the > binary should sign it (unless you think this is too involved). > > - Not including Dragonegg in the release; it seems pretty unmaintaned by > now. > > Please let me know what you think! > > Cheers, > Hans > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150623/1829abd1/attachment.html>
On 26 May 2015 at 17:57, Hans Wennborg <hans at chromium.org> wrote:> - Branch for 3.7 on 14 July 2015 > - Release 3.7 end of August (absolutely no later than 4 September)Sounds like a plan!> - Announce the first release candidate on llvm-announce to encourage > more early testing. Last time many issues were raised late in the > process. I'm sure that will happen this time too, but announcing the > RC to a wider audience might help mitigate some of that.I'm not sure llvm-announce is a larger audience, but won't hurt to CC it.> - Using CMake for the release binaries. I think I promised we'd do > this for 3.7. I haven't actually started looking at this yet, but I'm > still optimistic.I'm absolutely in agreement with this. Most of us already use CMake for development, a lot of the buildbots are based on it and I think we all agree that autoconf is deprecated. Makes no sense to still use it for releases.> - Provide a tarball with the docs and doxygen as part of the release.There's some of that already, though it never worked too well on my builds. I never cared, maybe I should.> - PGP signatures on pre-built binaries: the person who builds the > binary should sign it (unless you think this is too involved).I'm ok with this, but we need some process documentation, so that all of us releasing binaries do the exact same thing or users will be confused.> - Not including Dragonegg in the release; it seems pretty unmaintaned by now.I already don't for a long time... Maybe ever. :) In my wish-list for test-release, in addition to yours, is: 1. Check that all dependencies are met. Libraries, tools, Python modules, header files, etc. CMake will do most of it, so that may be covered by the move to it. 2. Check that the things you want to build are actually build. The script checks out everything (including dragonegg and libc++), but my final binaries never had any of them. Not even compiler-rt. This one I *will* start caring *very* soon. I'd like to have both RT and libcxx for 3.7. 3. Actually running the test-suite on the Phase3/install binaries. But for now, this is not priority for 3.7. I already have a script to do that on the side, similar to my new CMake test-suite buildbot [1]. cheers, --renato [1] http://lab.llvm.org:8011/builders/clang-native-arm-lnt
> > - Using CMake for the release binaries. I think I promised we'd do > > this for 3.7. I haven't actually started looking at this yet, but I'm > > still optimistic. > > I'm absolutely in agreement with this. Most of us already use CMake > for development, a lot of the buildbots are based on it and I think we > all agree that autoconf is deprecated. Makes no sense to still use it > for releases.I have mixed opinions on it. For the 32-bit Mips packages I normally do it's definitely a good thing (it allows me to ship sanitizers for one). However, I'm hoping to do Mips64 packages too and I recently discovered cmake problems with Mips64 and find_library(). I don't think this should stop everyone switching over to cmake but it would be good to retain the option of autoconf for a bit longer.> 2. Check that the things you want to build are actually build. The > script checks out everything (including dragonegg and libc++), but my > final binaries never had any of them. Not even compiler-rt. This one I > *will* start caring *very* soon. I'd like to have both RT and libcxx > for 3.7.I was surprised by the lack of compiler-rt in the Mips packages too. It turned out that only X86 built compiler-rt in an autoconf-based build.