LLVM 3.4 Branch Freeze

The LLVM 3.4 branches are now frozen. We’re only accepting major, super horrible bug fixes from now on. The testers are going to do a third phase of testing, but it’s mostly to verify that we don’t have any major problems left.

Share and enjoy!
-bw

Bill, et al.,

There are still a number of open bug reports demonstrating miscompiles on x86 with small/reduced test cases. I propose that we either delay this release until these have been fixed, or plan on a point release in the near future. I recommend that we put out another two release candidates, one at the end of this week, and one after another two weeks or so, to allow for these outstanding issues to be resolved.

Specifically, I think that these issues should be resolved prior to the release of 3.4:

PR18068 [BasicAA]
PR18067 [GVN]
PR16431 (multiple; I suspect covered by the previous two)
PR17638 [IndVarSimplify]
PR18223 [IndVarSimplify]
PR17473 [LSR]
PR18165 [LSR]
PR16729 [Loop Vectorizer]
PR17288 [Loop Vectorizer]
PR18102 [x86 backend or CodeGen]
PR18000 [x86 backend or CodeGen]
PR17504 [x86 backend or CodeGen]
PR17794
PR17073
PR16108

PR18042 [LCSSA] (This hits an assert, but may miscompile with NDEBUG)

Of course, the same underlying bug may be causing more than one of these, and at least some of these are already being worked on. Thoughts?

Thanks again,
Hal

That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.

-bw

How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point..

The usual procedure is to make time-based releases. So - "release
trunk and make sure it's stable enough" plus - fix any outstanding
regressions.

There is some text wrt this:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria

From: "Anton Korobeynikov" <anton@korobeynikov.info>
To: "C. Bergström" <cbergstrom@pathscale.com>
Cc: "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "Mailing List" <llvmdev@cs.uiuc.edu>
Sent: Friday, December 13, 2013 3:24:38 AM
Subject: Re: [LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze

The usual procedure is to make time-based releases. So - "release
trunk and make sure it's stable enough" plus - fix any outstanding
regressions.

There is some text wrt this:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria

Fair enough, however, I view releasing a compiler which is known to miscompile code on a tier-1 platform as a serious problem. Obviously, we cannot delay a release indefinitely, but it is completely practical to fix all of those bugs in a few weeks: they all have small test cases. I think that what we should do is put names next to as many of those as possible (to assign responsibility), and proceed under the assumption that we'll cut the final release candidate once those assigned bugs have been fixed (my guess is that there are only 5-7 underlying issues behind those various bugs I listed). There are more than enough of us that *work* on LLVM for this to be reasonable.

FWIW, when I started talking to people about using an LLVM-based compiler in production, a common response was, "how large of a code base have you compiled with it that gets the right answer?" -- and the problem has been that, when testing on multi-million-line internal codebases, miscompiles had been observed. I feel that, as a community, we should take a stronger stance against releasing code with miscompile bugs. Doing so seriously hurts our credibility. Obviously, we can't delay a release because someone somewhere feels that we miscompile something, but having small test cases is another story.

In short, I feel that going from initial branching to final release in ~1 month is a great goal, but I'd rather make it two months (as Bill points out, there are holidays in the middle) to eliminate these kinds of bugs. I think that, so long as everyone can understand what is going on, our metrics on "release blocking" bugs are clear, and our release manager observes steady progress, then delaying is preferable.

Finally, I think that very few of us that create products derived from LLVM/Clang strictly track the upstream release schedule, so I suspect that delaying for a few weeks won't affect any of our corporate contributors. Many of my colleagues say that, with gcc, they wait for the x.y.1 release before upgrading because the .0 is too buggy. But if we're not doing point releases, then I think we need tighter standards for release. Doing otherwise is not fair to our users.

Thanks again,
Hal

Hal Finkel <hfinkel@anl.gov> writes:

[snip]

Many of my colleagues say that, with gcc, they wait for
the x.y.1 release before upgrading because the .0 is too buggy. But if
we're not doing point releases, then I think we need tighter standards
for release. Doing otherwise is not fair to our users.

What happened to the LLVM/Clang maintenance release project?

Hal Finkel <hfinkel@anl.gov> writes:

[snip]

> Many of my colleagues say that, with gcc, they wait for
> the x.y.1 release before upgrading because the .0 is too buggy. But if
> we're not doing point releases, then I think we need tighter standards
> for release. Doing otherwise is not fair to our users.

What happened to the LLVM/Clang maintenance release project?

We weren't able to make a 3.3.1 release, because we did not have enough
testers.

In order to have a successful maintenance release, we need to either:

a) Get commitments from everyone who wants a maintenance release that
they will help test the release.

or

b) Have less strict testing requirements for maintenance releases with
   the assumption that there is a lot of ongoing testing between .0 and .1
   so there are less likely to be bugs left when it is time to release .1,
   and anyone who cares about a maintenance release has had enough time to file
   bugs.

I really think maintenance releases are really important for Open Source
projects, because these projects get much more testing after a release than
before it.

I would volunteer to maintain a stable branch again after the 3.4
release, but I think we need to solve our release validation issues first.

-Tom

I have set up some jenkins nodes to produce nightly packages for Debian
and Ubuntu for the 3.4 branches.
(I have some gcc-4.8 missing dependencies issues but they are not
directly related).

Sylvestre

Even if they take a long time to fix. What is the harm in adding a
test case for each one into the release 3.4 now?
It sounds to me that they are unlikely to be marked as "won't fix".
They will then come up as tests that fail and can be listed as "Known
bugs" in the release notes. Although there does not appear to be a
"Known bugs" list in the release notes at present.
Someone might even be able to use them to make an "automated compare"
that can compare them with various large projects and be able to
obtain an answer as to whether the project will compile correctly or
not with clang/llvm.

James

From: "Tom Stellard" <tom@stellard.net>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu
Sent: Friday, December 13, 2013 10:24:59 AM
Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze

> Hal Finkel <hfinkel@anl.gov> writes:
>
> [snip]
>
> > Many of my colleagues say that, with gcc, they wait for
> > the x.y.1 release before upgrading because the .0 is too buggy.
> > But if
> > we're not doing point releases, then I think we need tighter
> > standards
> > for release. Doing otherwise is not fair to our users.
>
> What happened to the LLVM/Clang maintenance release project?
>

We weren't able to make a 3.3.1 release, because we did not have
enough
testers.

In order to have a successful maintenance release, we need to either:

a) Get commitments from everyone who wants a maintenance release that
they will help test the release.

or

b) Have less strict testing requirements for maintenance releases
with
   the assumption that there is a lot of ongoing testing between .0
   and .1
   so there are less likely to be bugs left when it is time to
   release .1,
   and anyone who cares about a maintenance release has had enough
   time to file
   bugs.

I really think maintenance releases are really important for Open
Source
projects, because these projects get much more testing after a
release than
before it.

I would volunteer to maintain a stable branch again after the 3.4
release,

I would certainly also help.

but I think we need to solve our release validation issues
first.

To be honest, I don't think this will be a problem in practice. The amount of incremental change is small and there is already ongoing testing of all changes that go into the release (which should all be bug fixes). You may not get as much testing as for the primary release, but I suspect that many of those same people who test the base releases will also try the maintenance releases. Personally, yes, I'd contribute to testing the maintenance releases.

-Hal

Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then.

If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable. For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across.

There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time.

-bw

That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.

How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point..

Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then.

I think you're doing an awesome job and I don't disagree with anything you've written.. curiosity killed the cat though..

If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable.

I'm curious about why... release early, release often? stakeholder pressure or just trying to maintain a predictable release schedule

  For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across.

There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time.

If it wasn't affecting anyone - there wouldn't be a bug report. I won't speculate how many people that is though or the severity.. (Once again it's not a critique or disagreeing. ALL software has bugs.. just thinking-out-loud)

That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.

How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than “getting it right” - granted if it’s unlikely any fix date I can totally see your point…

Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then.

I think you’re doing an awesome job and I don’t disagree with anything you’ve written… curiosity killed the cat though…

If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable.

I’m curious about why… release early, release often? stakeholder pressure or just trying to maintain a predictable release schedule

To have a reasonably predictable release schedule. Also to release our testers up so that they aren’t bogged down by a really long release. And we have no assurance that the bugs will be fixed, because this is all a volunteer effort.

For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across.

There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time.

If it wasn’t affecting anyone - there wouldn’t be a bug report.

If I understand, it was an automated tool that reported some (all?) of those bugs. They test things that normal programmers don’t really do.

I won’t speculate how many people that is though or the severity… (Once again it’s not a critique or disagreeing. ALL software has bugs… just thinking-out-loud)

The reason why I said that is because some of those bugs have been in the tree for several releases now, and several large organizations have been using clang on a daily basis and haven’t ran into most of these (otherwise, they’d be fixed :slight_smile: ).

-bw

From: “Anton Korobeynikov” <anton@korobeynikov.info>
To: “C. Bergström” <cbergstrom@pathscale.com>
Cc: “cfe-dev@cs.uiuc.edu Developers” <cfe-dev@cs.uiuc.edu>, “Mailing List” <llvmdev@cs.uiuc.edu>
Sent: Friday, December 13, 2013 3:24:38 AM
Subject: Re: [LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze

The usual procedure is to make time-based releases. So - “release
trunk and make sure it’s stable enough” plus - fix any outstanding
regressions.

There is some text wrt this:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria

Fair enough, however, I view releasing a compiler which is known to miscompile code on a tier-1 platform as a serious problem.

I don’t disagree with this at all.

Obviously, we cannot delay a release indefinitely, but it is completely practical to fix all of those bugs in a few weeks: they all have small test cases. I think that what we should do is put names next to as many of those as possible (to assign responsibility), and proceed under the assumption that we’ll cut the final release candidate once those assigned bugs have been fixed (my guess is that there are only 5-7 underlying issues behind those various bugs I listed). There are more than enough of us that work on LLVM for this to be reasonable.

Those people have their own schedules and priorities. I have absolutely zero control over which bugs they give their time to. If I had someone say “I am working on this and foresee a fix by Monday,” then I would wait. But so far no one has done that.

FWIW, when I started talking to people about using an LLVM-based compiler in production, a common response was, “how large of a code base have you compiled with it that gets the right answer?” – and the problem has been that, when testing on multi-million-line internal codebases, miscompiles had been observed. I feel that, as a community, we should take a stronger stance against releasing code with miscompile bugs. Doing so seriously hurts our credibility. Obviously, we can’t delay a release because someone somewhere feels that we miscompile something, but having small test cases is another story.

In short, I feel that going from initial branching to final release in ~1 month is a great goal, but I’d rather make it two months (as Bill points out, there are holidays in the middle) to eliminate these kinds of bugs. I think that, so long as everyone can understand what is going on, our metrics on “release blocking” bugs are clear, and our release manager observes steady progress, then delaying is preferable.

Finally, I think that very few of us that create products derived from LLVM/Clang strictly track the upstream release schedule, so I suspect that delaying for a few weeks won’t affect any of our corporate contributors. Many of my colleagues say that, with gcc, they wait for the x.y.1 release before upgrading because the .0 is too buggy. But if we’re not doing point releases, then I think we need tighter standards for release. Doing otherwise is not fair to our users.

-bw

From: "Bill Wendling" <isanbard@gmail.com>
To: "C. Bergström" <cbergstrom@pathscale.com>
Cc: "Hal Finkel" <hfinkel@anl.gov>, "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "Mailing List"
<llvmdev@cs.uiuc.edu>
Sent: Monday, December 16, 2013 3:20:48 AM
Subject: Re: [cfe-dev] LLVM 3.4 Branch Freeze

That’s a long laundry list of bugs there. It would be great to have
them fixed, but the reality of the situation is that they won’t be
fixed for weeks or more, if at all. And with Christmas coming up, it
makes things even worse. There are a few days before Phase III
starts to have some progress on them. But if they don’t make it,
then we’ll have to release without them.
How is the release schedule and blockers decided - is there a policy?
As an open source project it seems sorta weird (to me) that rushing
a release is more important than "getting it right" - granted if
it's unlikely any fix date I can totally see your point..
Releasing software is more of an art than a science. Any software
release has bugs (not just our project, any project). The question
to ask is how severe are those bugs? The balance between the
severity and how many people are (potentially) impacted by it. Then
you should keep in mind that we have a 6-month release cycle. So any
bugs that aren’t fixed now will hopefully be fixed by then.
I think you're doing an awesome job and I don't disagree with
anything you've written.. curiosity killed the cat though..

If I wait for these bugs to be fixed, we won’t be releasing until
late January. And that’s really not acceptable.
I'm curious about why... release early, release often? stakeholder
pressure or just trying to maintain a predictable release schedule

To have a reasonably predictable release schedule. Also to release
our testers up so that they aren’t bogged down by a really long
release. And we have no assurance that the bugs will be fixed,
because this is all a volunteer effort.

For those who actively use LLVM as a library, they are encouraged to
keep current with the main trunk. For those who use the official
release, they should be made aware of any potential major bugs they
may come across.

There is evidence to suggest that these (admittedly severe) bugs,
some of which have been in the tree for several releases, aren’t
affecting many people at the moment. I would love to have them
fixed. But it’s not looking feasible at this time.
If it wasn't affecting anyone - there wouldn't be a bug report.

If I understand, it was an automated tool that reported some (all?)
of those bugs. They test things that normal programmers don’t really
do.

Almost all of them, and several different tools, as it turns out. Regarding whether these bugs occur in human-written code, I'd like to point out that Kay Tiong Khoo has been auditing many bugs that have been recently fixed (or hidden) by some unknown change. He's bisected a fair number of them down to fixes to other bugs. It might be interested to see how many of those were reported based on human-written code.

Regardless, I'd much rather fix a bug with a 40-line computer-generated test case, than in a million-line human-generated codebase :wink:

-Hal

> From: "Tom Stellard" <tom@stellard.net>
> To: "Óscar Fuentes" <ofv@wanadoo.es>
> Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu
> Sent: Friday, December 13, 2013 10:24:59 AM
> Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze
>
> > Hal Finkel <hfinkel@anl.gov> writes:
> >
> > [snip]
> >
> > > Many of my colleagues say that, with gcc, they wait for
> > > the x.y.1 release before upgrading because the .0 is too buggy.
> > > But if
> > > we're not doing point releases, then I think we need tighter
> > > standards
> > > for release. Doing otherwise is not fair to our users.
> >
> > What happened to the LLVM/Clang maintenance release project?
> >
>
> We weren't able to make a 3.3.1 release, because we did not have
> enough
> testers.
>
> In order to have a successful maintenance release, we need to either:
>
> a) Get commitments from everyone who wants a maintenance release that
> they will help test the release.
>
> or
>
> b) Have less strict testing requirements for maintenance releases
> with
> the assumption that there is a lot of ongoing testing between .0
> and .1
> so there are less likely to be bugs left when it is time to
> release .1,
> and anyone who cares about a maintenance release has had enough
> time to file
> bugs.
>
> I really think maintenance releases are really important for Open
> Source
> projects, because these projects get much more testing after a
> release than
> before it.
>
> I would volunteer to maintain a stable branch again after the 3.4
> release,

I would certainly also help.

> but I think we need to solve our release validation issues
> first.

To be honest, I don't think this will be a problem in practice. The amount of incremental change is small and there is already ongoing testing of all changes that go into the release (which should all be bug fixes). You may not get as much testing as for the primary release, but I suspect that many of those same people who test the base releases will also try the maintenance releases. Personally, yes, I'd contribute to testing the maintenance releases.

Maybe we can re-visit this after the holidays are over. I am still
interested in doing bugfix releases for LLVM.

Besides the issue with testers the other thing we need to determine is
whether or not we want to maintain a stable ABI for the bugfix releases.
With 3.3, the plan was to have a stable ABI, but this caused me to
reject several fixes. I would recommend relaxing this requirement
if there is are bugfix releases for 3.4, but I'd like to hear what other
people think about this.

-Tom

From: "Tom Stellard" <tom@stellard.net>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu, "Óscar Fuentes" <ofv@wanadoo.es>
Sent: Wednesday, December 18, 2013 10:55:43 AM
Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze

> > From: "Tom Stellard" <tom@stellard.net>
> > To: "Óscar Fuentes" <ofv@wanadoo.es>
> > Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu
> > Sent: Friday, December 13, 2013 10:24:59 AM
> > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze
> >
> > > Hal Finkel <hfinkel@anl.gov> writes:
> > >
> > > [snip]
> > >
> > > > Many of my colleagues say that, with gcc, they wait for
> > > > the x.y.1 release before upgrading because the .0 is too
> > > > buggy.
> > > > But if
> > > > we're not doing point releases, then I think we need tighter
> > > > standards
> > > > for release. Doing otherwise is not fair to our users.
> > >
> > > What happened to the LLVM/Clang maintenance release project?
> > >
> >
> > We weren't able to make a 3.3.1 release, because we did not have
> > enough
> > testers.
> >
> > In order to have a successful maintenance release, we need to
> > either:
> >
> > a) Get commitments from everyone who wants a maintenance release
> > that
> > they will help test the release.
> >
> > or
> >
> > b) Have less strict testing requirements for maintenance releases
> > with
> > the assumption that there is a lot of ongoing testing between
> > .0
> > and .1
> > so there are less likely to be bugs left when it is time to
> > release .1,
> > and anyone who cares about a maintenance release has had
> > enough
> > time to file
> > bugs.
> >
> > I really think maintenance releases are really important for Open
> > Source
> > projects, because these projects get much more testing after a
> > release than
> > before it.
> >
> > I would volunteer to maintain a stable branch again after the 3.4
> > release,
>
> I would certainly also help.
>
> > but I think we need to solve our release validation issues
> > first.
>
> To be honest, I don't think this will be a problem in practice. The
> amount of incremental change is small and there is already ongoing
> testing of all changes that go into the release (which should all
> be bug fixes). You may not get as much testing as for the primary
> release, but I suspect that many of those same people who test the
> base releases will also try the maintenance releases. Personally,
> yes, I'd contribute to testing the maintenance releases.
>

Maybe we can re-visit this after the holidays are over. I am still
interested in doing bugfix releases for LLVM.

Sounds good; let's do that.

Besides the issue with testers the other thing we need to determine
is
whether or not we want to maintain a stable ABI for the bugfix
releases.
With 3.3, the plan was to have a stable ABI, but this caused me to
reject several fixes. I would recommend relaxing this requirement
if there is are bugfix releases for 3.4, but I'd like to hear what
other
people think about this.

What kinds of changes were made? (can you provide a couple of examples)?

-Hal

Here are a few examples:
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018

-Tom

From: "Tom Stellard" <tom@stellard.net>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu, "Óscar Fuentes" <ofv@wanadoo.es>
Sent: Wednesday, December 18, 2013 11:07:23 AM
Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze

> > From: "Tom Stellard" <tom@stellard.net>
> > To: "Hal Finkel" <hfinkel@anl.gov>
> > Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu, "Óscar Fuentes"
> > <ofv@wanadoo.es>
> > Sent: Wednesday, December 18, 2013 10:55:43 AM
> > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze
> >
> > > > From: "Tom Stellard" <tom@stellard.net>
> > > > To: "Óscar Fuentes" <ofv@wanadoo.es>
> > > > Cc: cfe-dev@cs.uiuc.edu, llvmdev@cs.uiuc.edu
> > > > Sent: Friday, December 13, 2013 10:24:59 AM
> > > > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze
> > > >
> > > > > Hal Finkel <hfinkel@anl.gov> writes:
> > > > >
> > > > > [snip]
> > > > >
> > > > > > Many of my colleagues say that, with gcc, they wait for
> > > > > > the x.y.1 release before upgrading because the .0 is too
> > > > > > buggy.
> > > > > > But if
> > > > > > we're not doing point releases, then I think we need
> > > > > > tighter
> > > > > > standards
> > > > > > for release. Doing otherwise is not fair to our users.
> > > > >
> > > > > What happened to the LLVM/Clang maintenance release
> > > > > project?
> > > > >
> > > >
> > > > We weren't able to make a 3.3.1 release, because we did not
> > > > have
> > > > enough
> > > > testers.
> > > >
> > > > In order to have a successful maintenance release, we need to
> > > > either:
> > > >
> > > > a) Get commitments from everyone who wants a maintenance
> > > > release
> > > > that
> > > > they will help test the release.
> > > >
> > > > or
> > > >
> > > > b) Have less strict testing requirements for maintenance
> > > > releases
> > > > with
> > > > the assumption that there is a lot of ongoing testing
> > > > between
> > > > .0
> > > > and .1
> > > > so there are less likely to be bugs left when it is time
> > > > to
> > > > release .1,
> > > > and anyone who cares about a maintenance release has had
> > > > enough
> > > > time to file
> > > > bugs.
> > > >
> > > > I really think maintenance releases are really important for
> > > > Open
> > > > Source
> > > > projects, because these projects get much more testing after
> > > > a
> > > > release than
> > > > before it.
> > > >
> > > > I would volunteer to maintain a stable branch again after the
> > > > 3.4
> > > > release,
> > >
> > > I would certainly also help.
> > >
> > > > but I think we need to solve our release validation issues
> > > > first.
> > >
> > > To be honest, I don't think this will be a problem in practice.
> > > The
> > > amount of incremental change is small and there is already
> > > ongoing
> > > testing of all changes that go into the release (which should
> > > all
> > > be bug fixes). You may not get as much testing as for the
> > > primary
> > > release, but I suspect that many of those same people who test
> > > the
> > > base releases will also try the maintenance releases.
> > > Personally,
> > > yes, I'd contribute to testing the maintenance releases.
> > >
> >
> > Maybe we can re-visit this after the holidays are over. I am
> > still
> > interested in doing bugfix releases for LLVM.
>
> Sounds good; let's do that.
>
> >
> > Besides the issue with testers the other thing we need to
> > determine
> > is
> > whether or not we want to maintain a stable ABI for the bugfix
> > releases.
> > With 3.3, the plan was to have a stable ABI, but this caused me
> > to
> > reject several fixes. I would recommend relaxing this
> > requirement
> > if there is are bugfix releases for 3.4, but I'd like to hear
> > what
> > other
> > people think about this.
>
> What kinds of changes were made? (can you provide a couple of
> examples)?
>

Here are a few examples:
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018

I think that we should keep source compatibility, not necessarily binary compatibility, in maintenance releases. Binary compatibility, when possible, is nice, but should not stand in the way of the bug fixes themselves.

Some of the packagers should comment on this topic :slight_smile:

-Hal