Please let me know if you'd like to help providing binaries and
testing for your favourite platform. If you were a tester on the
previous release, I've bcc'd you on this email.
I propose this schedule for the 3.7 release:
- 14 July 2015: Create the release branch.
- 14 July -- 21 July: Testing Phase I. RC1 binaries are built and tested.
- 22 July -- 29 July: Fix bugs from Testing Phase I. All new features
for the release should be complete. Incomplete features need to be
turned off by default.
- 30 July -- 6 August: Testing Phase I. RC2 binaries are built and tested.
- 7 August - 14 August: Fix bugs from Testing Phase II. Only critical
bug fixes are accepted.
- 21 August: Release 3.7.0.
Unless there are any objections, I will post this on the web page soon.
Please let me know if you'd like to help providing binaries and
testing for your favourite platform. If you were a tester on the
previous release, I've bcc'd you on this email.
I'll be doing the FreeBSD binaries and testing, as usual.
I propose this schedule for the 3.7 release:
- 14 July 2015: Create the release branch.
- 14 July -- 21 July: Testing Phase I. RC1 binaries are built and tested.
- 22 July -- 29 July: Fix bugs from Testing Phase I. All new features
for the release should be complete. Incomplete features need to be
turned off by default.
- 30 July -- 6 August: Testing Phase I. RC2 binaries are built and tested.
- 7 August - 14 August: Fix bugs from Testing Phase II. Only critical
bug fixes are accepted.
- 21 August: Release 3.7.0.
It looks good to me, though during this time, some people may be on vacation, at least part of the time?
Count me in, Fedora and openSUSE, and just so you know, I genuinely dislike them both
P.S. I had a look at your batch file for building on windows but I noticed that it doesn’t do a full bootstrap? I guess it’ll be fixed once we move to CMake releases?
My main issue is that find_library() doesn't work correctly on Debian Jessie (mips/mipsel) for the 64-bit multilibs. It variously finds libraries that aren’t really available (although in some cases it links regardless), fails to find libraries that are available, and links against incompatible libraries. Autoconf on the other hand does the right thing for 64-bit but disables some projects such as compiler-rt.
I'm in favour of moving to cmake in general. I just need to retain the option of autoconf to have a chance to ship an initial Mips64 package.
Yes, I realize this, and it's a little unfortunate, but hopefully
enough folks are around and the process long enough that it will work
out.
If this turns out to be a real problem, we could consider slipping
future releases a little further into the year, but I'd really like to
avoid that and stick to the current 6-month cycle if possible.
Right, I should probably try that. We're already using CMake for the
Windows binaries, so it's just a matter of updating the script and
making sure it works. I'll see if I can get this done for the next
snapshot.
My main issue is that find_library() doesn't work correctly on Debian Jessie (mips/mipsel) for the 64-bit multilibs. It variously finds libraries that aren’t really available (although in some cases it links regardless), fails to find libraries that are available, and links against incompatible libraries. Autoconf on the other hand does the right thing for 64-bit but disables some projects such as compiler-rt.
I'm in favour of moving to cmake in general. I just need to retain the option of autoconf to have a chance to ship an initial Mips64 package.
Right, as discussed on the other thread, since some things still don't
build with cmake, I'll make the release script support both options.
We'll use cmake where we can, and fall back to autoconf when we have
to.
I will be on vacation during the qualification time, but if anyone comes up with new CMake bugs that block creating packages please mark them as blocking PR15732 (https://llvm.org/bugs/show_bug.cgi?id=15732).
+lldb-dev, which I should have included in the first place.
lldb hasn't been a major part of the release process before. There are
no pre-built binaries, and I don't think it has seen much testing in
previous releases.
However, it still gets a release branch and tags, and the source is
part of the release. I'm hoping there are folks willing to test it and
make sure the release version of lldb works nicely with the release
version of llvm, etc.
I'd like to help with the lldb release process on the linux platform,
but I'm kinda new to this, so I would appreciate if you could explain
it to me what would this involve.
I'd like to help with the lldb release process on the linux platform,
but I'm kinda new to this, so I would appreciate if you could explain
it to me what would this involve.
The main objective is to make sure everything compiles and works in
the released version of the code, so checking out and testing the code
once we've branched, filing bugs and trying to get them fixed is
basically what the release is all about.
For Clang and the main llvm libraries, we provide pre-built binaries
in the release, built with the utils/release/test-release.sh script. I
don't know if it would be practical to do this for lldb as well.
The main objective is to make sure everything compiles and works in
the released version of the code, so checking out and testing the code
once we’ve branched, filing bugs and trying to get them fixed is
basically what the release is all about.
I’ll do this for FreeBSD (unless Dimitry gets to it first).
For Clang and the main llvm libraries, we provide pre-built binaries
in the release, built with the utils/release/test-release.sh script. I
don’t know if it would be practical to do this for lldb as well.
We could, but I don’t think there is nearly as much value in doing this for lldb as for clang/llvm.
