Hey,
Regarding the GCC ABI 5 issue, I was wondering what's the policy behind updating packages on stable updates for both Debian and Ubuntu.
Our time frame is a bit constrained, and we definitely will have to take some hard decisions in the next six months, so I'd like to understand everything that is at stake before I have my own opinion.
LLVM has a 6 month major cycle, releasing around February / August. Major releases are allowed to break the ABI. Major breakages need one release warning period.
Ubuntu has a 6 month release cycle, around April / October. IIUC, major releases are allowed to have new versions of packages, but updates for the next few years have to keep within the same major release.
Debian has a -1 years release cycle (heh), and has the same major / minor policy, which makes it a lot harder to update major versions. However, I believe unstable is still not closed, nor will be in August this year, so updating to LLVM 3.9 will not be a problem, but it will mean users will have to wait a bit more to get a working LLVM.
The time frame is then:
3.8.0 released March (without the fix) Ubuntu X released April 3.9.0 releases August (hopefully with a fix) Ubuntu X+1 released October
Debian freezes ?? LLVM 3.8.1 ??
If we don't back-port GCC ABI 5 into 3.8.1, Ubuntu users will not have the fix ever, unless you *can* update to 3.9.0 in August.
Ubuntu X+1 will be fine using 3.9, as will Debian after August, unless you guys freeze before that.
I believe both Debian and Ubuntu have a trunk-based LLVM package for experimental use only, and it would be bad, but not completely broken, to recommend users to use that meanwhile.
If Debian freezes *before* 3.9.0 is out, or if Ubuntu can't update to 3.9.0 on April's release, then we'll have a strong reason to back-port the change to 3.8.x. If not, even though it will be uncomfortable for users until August, the argument is not that strong and will be hard to get it through.
Any comments? Ideas? Does any of that make sense?
cheers, --renato
On 13.03.2016 12:04, Renato Golin wrote:
Hey,
Regarding the GCC ABI 5 issue, I was wondering what's the policy behind updating packages on stable updates for both Debian and Ubuntu.
Our time frame is a bit constrained, and we definitely will have to take some hard decisions in the next six months, so I'd like to understand everything that is at stake before I have my own opinion.
LLVM has a 6 month major cycle, releasing around February / August. Major releases are allowed to break the ABI. Major breakages need one release warning period.
Ubuntu has a 6 month release cycle, around April / October. IIUC, major releases are allowed to have new versions of packages, but updates for the next few years have to keep within the same major release.
except for the LTS releases, which have a two year release cycle. 16.04 LTS will be the next LTS.
Debian has a -1 years release cycle (heh), and has the same major / minor policy, which makes it a lot harder to update major versions.
This is more like a 18-24 months cycle.
However, I believe unstable is still not closed, nor will be in August this year, so updating to LLVM 3.9 will not be a problem, but it will mean users will have to wait a bit more to get a working LLVM.
As announced on debian-devel-announce, the freeze will be in Feb 2017.
The time frame is then:
3.8.0 released March (without the fix) Ubuntu X released April 3.9.0 releases August (hopefully with a fix) Ubuntu X+1 released October
Debian freezes ?? LLVM 3.8.1 ??
If we don't back-port GCC ABI 5 into 3.8.1, Ubuntu users will not have the fix ever, unless you *can* update to 3.9.0 in August.
Ubuntu LTS users won't see any 3.9 updates in August. So yes, a backport of these changes to 3.8.1 would be appreciated.
Ubuntu X+1 will be fine using 3.9, as will Debian after August, unless you guys freeze before that.
While I'm still listed as an uploader for some llvm packages in Debian; I'm only contributing some build fixes to the Debian packages if I see these, however the roadmap for Debian maybe should be to go with 3.9 as the default for the release, and maybe keep some legacy versions (I assume at least haskell needs 3.5).
Ubuntu usually adds new llvm versions after release as part of the regular xserver/mesa updates, using a llvm-x.y version in a newer Ubuntu release. So you might get 3.9 into 16.04 LTS either in late 2016 (after the 16.10 release), or in mid 2017 (after the 17.04 release).
I believe both Debian and Ubuntu have a trunk-based LLVM package for experimental use only, and it would be bad, but not completely broken, to recommend users to use that meanwhile.
Debian keeps these in experimental, which is not recommended for "users"; Ubuntu keeps these in the -proposed pocket only, these package never reach the release pocket, even during development of a new release. So you can't safely point users to this version.
If Debian freezes *before* 3.9.0 is out, or if Ubuntu can't update to 3.9.0 on April's release, then we'll have a strong reason to back-port the change to 3.8.x. If not, even though it will be uncomfortable for users until August, the argument is not that strong and will be hard to get it through.
Any comments? Ideas? Does any of that make sense?
So from my point of view, I'd like to see these patches on the 3.8 branch, or on a separate branch, if upstream thinks that these are not suitable for the 3.8 branch.
Matthias
On 13 March 2016 at 18:42, Matthias Klose doko@ubuntu.com wrote:
except for the LTS releases, which have a two year release cycle. 16.04 LTS will be the next LTS.
Damn it.
As announced on debian-devel-announce, the freeze will be in Feb 2017.
Ok, less problematic in Debian's case.
Ubuntu LTS users won't see any 3.9 updates in August. So yes, a backport of these changes to 3.8.1 would be appreciated.
Damn it. :)
While I'm still listed as an uploader for some llvm packages in Debian; I'm only contributing some build fixes to the Debian packages if I see these, however the roadmap for Debian maybe should be to go with 3.9 as the default for the release, and maybe keep some legacy versions (I assume at least haskell needs 3.5).
That'd be ok, since Haskell will probably not be affected by the ABI bug.
But you should make sure you mark that version as deprecated and as not fulfilling the "llvm" requirement, so that packages don't accept llvm-3.5 as a dependency.
Ubuntu usually adds new llvm versions after release as part of the regular xserver/mesa updates, using a llvm-x.y version in a newer Ubuntu release. So you might get 3.9 into 16.04 LTS either in late 2016 (after the 16.10 release), or in mid 2017 (after the 17.04 release).
If this happens, could it become the default, replacing 3.8?
Debian keeps these in experimental, which is not recommended for "users"; Ubuntu keeps these in the -proposed pocket only, these package never reach the release pocket, even during development of a new release. So you can't safely point users to this version.
Ok.
So from my point of view, I'd like to see these patches on the 3.8 branch, or on a separate branch, if upstream thinks that these are not suitable for the 3.8 branch.
It's either 3.8 or nothing. We don't do multiple release branches, so once 3.9 is out, there will be no more 3.8.x (or 3.7.x, foobar, etc).
Once the ABI is fixed in trunk, we shall start the discussion about the back-port. I think we have enough information to take it to the community and make sure we take the right decision for all affected parties.
Thanks! --renato
linaro-toolchain@lists.linaro.org