Hi Tom, On 9 Jun 2014, at 15:36, Tom Stellard <tom at stellard.net> wrote:> Unfortunately, it is too late to get this into 3.4.2. With the 3.5 > release coming soon, I wasn't planning on doing another 3.4 point > release.We are likely to keep the llvm 3.4 port in FreeBSD for a while after 3.5 is released. We've only removed the llvm 3.1 port a couple of months ago. A few things still depend on LLVM 3.2, a few more on LLVM 3.3, so they're going to stay for a bit too. The lack of any vague nods in the direction of API stability or deprecation mechanisms mean that there's always a moderate lag (2 years seems about normal) between an LLVM release being superseded and all dependent projects being upgraded (or, in some cases, abandoned). This means that, if you have the time do to it, keeping the 3.4.x branch alive would likely be valuable. David
On Mon, Jun 09, 2014 at 03:54:32PM +0100, David Chisnall wrote:> Hi Tom, > > On 9 Jun 2014, at 15:36, Tom Stellard <tom at stellard.net> wrote: > > > Unfortunately, it is too late to get this into 3.4.2. With the 3.5 > > release coming soon, I wasn't planning on doing another 3.4 point > > release. > > We are likely to keep the llvm 3.4 port in FreeBSD for a while after 3.5 is released. We've only removed the llvm 3.1 port a couple of months ago. A few things still depend on LLVM 3.2, a few more on LLVM 3.3, so they're going to stay for a bit too. The lack of any vague nods in the direction of API stability or deprecation mechanisms mean that there's always a moderate lag (2 years seems about normal) between an LLVM release being superseded and all dependent projects being upgraded (or, in some cases, abandoned). > > This means that, if you have the time do to it, keeping the 3.4.x branch alive would likely be valuable.I'm not opposed to doing more 3.4.x releases, we just need to make sure that if we continue the 3.4.x series that each release has fixes with a broad enough appeal that it justifies the time spent by the community testers. I suspect that we could automate most of the release process with bots, so if we could find a good solution for this, then it would be much easier to keep stable branches going longer, since we wouldn't need to rely on the time of human testers. Once 3.5 is released, then 3.5.x will become more interesting to me than 3.4.x, so I'm not sure I will have the time to keep the 3.4.x series going. However, if someone else would like to volunteer to continue managing 3.4.x releases, I will not object. -Tom
On 16 June 2014 17:00, Tom Stellard <tom at stellard.net> wrote:> I suspect that we could automate most of the release process with bots, so > if we could find a good solution for this, then it would be much easier to > keep stable branches going longer, since we wouldn't need to rely on the > time of human testers.Assuming nothing goes wrong, as with 3.4.2, it's not such a big pain to test and release to each one of us, testers. I heard some people do the release test on buildbots (by monitoring the release branch commits, not trunk). While that's a good idea, the main problems are hardware availability (for those of us that don't have too many devices to test, and trunk is more important), and making sure that all bots (check, self-hosting, LNT) are validated (for whatever meaning of validation) before the binaries are uploaded on the SFTP site. These are non-trivial constraints.> Once 3.5 is released, then 3.5.x will become more interesting to me than > 3.4.x, so I'm not sure I will have the time to keep the 3.4.x series > going. However, if someone else would like to volunteer to continue > managing 3.4.x releases, I will not object.I agree this is a good idea. I'm not too interested in point releases, myself, but I'll keep testing them. However, being a release manager is no easy task, and I wouldn't force that on anyone just to keep it up. I'd happily test 3.4.3 if anyone else decides to be the 3.4.x release manager from now on, though. cheers, --renato