Re: [opensuse-project] [Announcement] SUSE Release SLE Sources to openSUSE Project
SUSE is preparing to pro-actively release a significant portion of the SUSE Linux Enterprise source code,[...], to the openSUSE project. These packages will give the community an enduring, stable, and maintained base, upon which exciting[...]
Mighty goodlord, this is too much salestalk/marketspeak. The significant portion of SLE code is from openSUSE and/or other open projects anyway, so that may not be all that exciting.
An openSUSE community distribution built upon this base can plan for a sustainable stream of packages, as we intend to continue releasing and updating this platform in line with the cadence of SUSE Linux Enterprise and it's [sic] service packs.
Reads to me like "The openSUSE distribution converges with SLE and the two become the new SUSE Linux (open, this time)". Would not even be bad. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 29 April 2015 at 18:04, Jan Engelhardt <jengelh@inai.de> wrote:
SUSE is preparing to pro-actively release a significant portion of the SUSE Linux Enterprise source code,[...], to the openSUSE project. These packages will give the community an enduring, stable, and maintained base, upon which exciting[...]
Mighty goodlord, this is too much salestalk/marketspeak.
:) Sorry, that's the nature of such announcements - I promise to be more human when I talk about it on Friday
The significant portion of SLE code is from openSUSE and/or other open projects anyway, so that may not be all that exciting.
While that's partially true, I want to highlight that this includes maintenance updates. That's certainly something new, and I think exciting. More details on Friday (and to follow in the discussions and such after I'm sure)
An openSUSE community distribution built upon this base can plan for a sustainable stream of packages, as we intend to continue releasing and updating this platform in line with the cadence of SUSE Linux Enterprise and it's [sic] service packs.
Reads to me like "The openSUSE distribution converges with SLE and the two become the new SUSE Linux (open, this time)".
Would not even be bad.
I wouldn't put it that way, but I think you're on the right track. My talk will hopefully put some more 'meat on the bones' of such ideas so we can discuss the best way forward. PS. Please try and keep the discussions centred to opensuse-project for now, I don't want to have to monitor all of our lists for everyone's feedback, especially while I'm travelling to oSC -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wednesday 2015-04-29 18:15, Richard Brown wrote:
While that's partially true, I want to highlight that this includes maintenance updates. That's certainly something new, and I think exciting. More details on Friday (and to follow in the discussions and such after I'm sure)
R.Brown in his presentation on openSUSE:Next :
"How the heck are we going to build it"
1. Create and populate openSUSE:Essence (I'm trying to avoid shared "core" here since that was once used for Fedora already) 2. Create openSUSE:13.3 with a <path project="openSUSE:Essence"/>, which means it can override packages with newer versions as desired. 3. Cherry-pick (osc sr --no-cleanup) from openSUSE:Factory into openSUSE:Essence as desired. 4. Cherry-pick from openSUSE:Factory into openSUSE:13.3 as desired, much like it was already done for the time between branching off openSUSE:Factory and releasing a new openSUSE:x.y.
When to have the first release of openSUSE:13.3
Whatever floats. In particular though, regarding package selection, I do have the following constraints: - no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-) - kernel and glibc shall be refreshed for releases. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-)
It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE.
- kernel and glibc shall be refreshed for releases.
Why? Any technical reasons or just so? Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 01.05.2015 um 13:20 schrieb Stephan Kulow:
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-)
It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE.
Before it's misunderstood: the 3.16 kernel in 13.2 is maintained as long as 13.2 is - replace 3.16 with 4.$SOMERANDOMNUMBER in my argument :) Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Friday 2015-05-01 13:20, Stephan Kulow wrote:
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-)
It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE. Before it's misunderstood: the 3.16 kernel in 13.2 is maintained as long as 13.2 is - replace 3.16 with 4.$SOMERANDOMNUMBER in my argument :)
The point is that there are features that you cannot backstep from. For example, kernelnewbies.org says about 3.16: "In this release, XFS has added a btree that tracks free inodes. This feature adds does not change existing on-disk structures, but adds a new one that must remain consistent with the inode allocation btree; for this reason older kernels will only be able to mount read-only filesystems with the free inode btree feature." Whatever kernel is picked for 13.3, if it is less than 3.16, people could run into a problem for something that worked before. I have not found the new flags on my XFS superblocks yet, but that does not have to mean anything.
- kernel and glibc shall be refreshed for releases.
Why? Any technical reasons or just so?
No technical reasons, just practical ones. Sometimes there is new clunky hardware that needs something that is not 2 years old. Or because they made working with btrfs more endurable (fast device replacement in e.g. 3.19) for everyone. I kind of like how gcc does its multiversioning: it allows you to optionally install a newer one _from the same repository_. That one may be an unmaintained Tech Preview, but that would be good enough for me. The only issue is that kernel-*s share the same package name while gcc does not, so that has some implications how OBS selects them for build :/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 01.05.2015 um 14:08 schrieb Jan Engelhardt:
On Friday 2015-05-01 13:20, Stephan Kulow wrote:
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-)
It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE. Before it's misunderstood: the 3.16 kernel in 13.2 is maintained as long as 13.2 is - replace 3.16 with 4.$SOMERANDOMNUMBER in my argument :)
The point is that there are features that you cannot backstep from. For example, kernelnewbies.org says about 3.16: "In this release, XFS has added a btree that tracks free inodes. This feature adds does not change existing on-disk structures, but adds a new one that must remain consistent with the inode allocation btree; for this reason older kernels will only be able to mount read-only filesystems with the free inode btree feature."
Whatever kernel is picked for 13.3, if it is less than 3.16, people could run into a problem for something that worked before. I have not found the new flags on my XFS superblocks yet, but that does not have to mean anything.
Can we agree on: 13.3 kernel needs to be able to cope with filesystems created with 13.2 and leave out version numbers? Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Do we have a timetable for when the video will be posted? I’d love to comment but I’d like to see what was said first. Sincerely, Bob Martens
On May 1, 2015, at 7:16 AM, Stephan Kulow <coolo@suse.de> wrote:
Am 01.05.2015 um 14:08 schrieb Jan Engelhardt:
On Friday 2015-05-01 13:20, Stephan Kulow wrote:
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-)
It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE. Before it's misunderstood: the 3.16 kernel in 13.2 is maintained as long as 13.2 is - replace 3.16 with 4.$SOMERANDOMNUMBER in my argument :)
The point is that there are features that you cannot backstep from. For example, kernelnewbies.org says about 3.16: "In this release, XFS has added a btree that tracks free inodes. This feature adds does not change existing on-disk structures, but adds a new one that must remain consistent with the inode allocation btree; for this reason older kernels will only be able to mount read-only filesystems with the free inode btree feature."
Whatever kernel is picked for 13.3, if it is less than 3.16, people could run into a problem for something that worked before. I have not found the new flags on my XFS superblocks yet, but that does not have to mean anything.
Can we agree on: 13.3 kernel needs to be able to cope with filesystems created with 13.2
and leave out version numbers?
Greetings, Stephan
-- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Friday 2015-05-01 14:16, Stephan Kulow wrote:
- no downgrades relative to the versions that already were present in 13.2
there are features that you cannot backstep from. 3.16: "In this release, XFS has added[...]
Can we agree on: 13.3 kernel needs to be able to cope with filesystems created with 13.2
and leave out version numbers?
Of course my take was on features, not version numbers, and in any software, not just the kernel. When a downgrade is envisioned, that means there have to be backports for _all_ the features that were already previously included, and I doubt all of them can be found. That backporting onto old versions also requires more time. Remember the 1000-patch mess that systemd was a handful of weeks back. Certainly not want to do that again. A so-patched version then also fails to resemble anything in original documentation, creating confusion whereever you look. Time and again, I have people emailing me about xtables-addons(-1.x) which, while it supports 2.6.32, does not support whatever RHEL calls "2.6.32". Or more globally put, upstream will rightfully call them bastardized versions and at worst refuse assistance. No downgrades (slew it like ntp), no feature backports (bump package instead), no version games. These are my openSUSE ideals. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 01.05.2015 um 16:48 schrieb Jan Engelhardt:
A so-patched version then also fails to resemble anything in original documentation, creating confusion whereever you look. Time and again, I have people emailing me about xtables-addons(-1.x) which, while it supports 2.6.32, does not support whatever RHEL calls "2.6.32". Or more globally put, upstream will rightfully call them bastardized versions and at worst refuse assistance.
No downgrades (slew it like ntp), no feature backports (bump package instead), no version games. These are my openSUSE ideals.
I can agree to these ideals - no doubt. The question is: can the openSUSE project afford to live these ideals or are we better off with doing Tumbleweed according to the "upstream first" policy and leave the dirty patching of systemd to SUSE. RHEL and SLE will not stop creating these bastards because their businesses require it. And yes, upstreams often refuse assistance and they rightfully do. But still I don't really see too many openSUSE contributors interested in fixing bugs in systemd versions released with openSUSE releases. Usually the answer the reporter gets is: fixed in upstream/Factory. So I don't think current openSUSE releases serve the typical user's needs best. But that's who we make them for, aren't we? We don't do them to please xtable-addons upstream - so perhaps we should stop caring for them as our main concern. Greetings, Stephan P.S. this might have been the longest mail I wrote in a year or so :) -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Would it be possible to combine this thread with the other one titled "After the Richard talk... what's new for openSUSE”? Sincerely, Bob Martens
On May 1, 2015, at 10:45 AM, Stephan Kulow <coolo@suse.de> wrote:
Am 01.05.2015 um 16:48 schrieb Jan Engelhardt:
A so-patched version then also fails to resemble anything in original documentation, creating confusion whereever you look. Time and again, I have people emailing me about xtables-addons(-1.x) which, while it supports 2.6.32, does not support whatever RHEL calls "2.6.32". Or more globally put, upstream will rightfully call them bastardized versions and at worst refuse assistance.
No downgrades (slew it like ntp), no feature backports (bump package instead), no version games. These are my openSUSE ideals.
I can agree to these ideals - no doubt.
The question is: can the openSUSE project afford to live these ideals or are we better off with doing Tumbleweed according to the "upstream first" policy and leave the dirty patching of systemd to SUSE. RHEL and SLE will not stop creating these bastards because their businesses require it. And yes, upstreams often refuse assistance and they rightfully do. But still I don't really see too many openSUSE contributors interested in fixing bugs in systemd versions released with openSUSE releases. Usually the answer the reporter gets is: fixed in upstream/Factory. So I don't think current openSUSE releases serve the typical user's needs best. But that's who we make them for, aren't we? We don't do them to please xtable-addons upstream - so perhaps we should stop caring for them as our main concern.
Greetings, Stephan P.S. this might have been the longest mail I wrote in a year or so :)
-- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Friday 2015-05-01 17:53, Robert Martens wrote:
Would it be possible to combine this thread with the other one titled "After the Richard talk... what's new for openSUSE”?
- Messages already sent cannot be edited anymore. - most MUAs that do support threaded views don't support displaying the tree graphics for more than once ancestor - so practically: no Now, don't blame me, I did not start a new disconnected thread but set reply to Richard's own original post ;-) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Friday 2015-05-01 17:45, Stephan Kulow wrote:
Am 01.05.2015 um 16:48 schrieb Jan Engelhardt:
No downgrades, no feature backports, no version games. These are my openSUSE ideals.
I can agree to these ideals - no doubt.
The question is: can the openSUSE project afford to live these ideals or are we better off with doing Tumbleweed according to the "upstream first" policy and leave the dirty patching of systemd to SUSE.
IMO we lived very well by these ideals, up to and including openSUSE 13.2, and living them does not necessarily mean forcing Upstream First just to approach the ideals asymptotically faster.
But still I don't really see too many openSUSE contributors interested in fixing bugs in systemd versions released with openSUSE releases. Usually the answer the reporter gets is: fixed in upstream/Factory.
I would not find that surprising, given the o:F one has 79 patches, and the one in openSUSE:13.2 has 539. :-) We are already improving, let's re-test this after the next release. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 05/01/2015 09:48 AM, Jan Engelhardt wrote:
On Friday 2015-05-01 14:16, Stephan Kulow wrote:
- no downgrades relative to the versions that already were present in 13.2
there are features that you cannot backstep from. 3.16: "In this release, XFS has added[...]
Can we agree on: 13.3 kernel needs to be able to cope with filesystems created with 13.2
and leave out version numbers?
Of course my take was on features, not version numbers, and in any software, not just the kernel. When a downgrade is envisioned, that means there have to be backports for _all_ the features that were already previously included, and I doubt all of them can be found.
That backporting onto old versions also requires more time. Remember the 1000-patch mess that systemd was a handful of weeks back. Certainly not want to do that again.
A so-patched version then also fails to resemble anything in original documentation, creating confusion whereever you look. Time and again, I have people emailing me about xtables-addons(-1.x) which, while it supports 2.6.32, does not support whatever RHEL calls "2.6.32". Or more globally put, upstream will rightfully call them bastardized versions and at worst refuse assistance.
No downgrades (slew it like ntp), no feature backports (bump package instead), no version games. These are my openSUSE ideals.
With kernel backports, please do not get into the business of changing kernel APIs the way that Ubuntu and RHEL are doing. That becomes a horrible mess for people like me that are supporting out-of-tree drivers. It has gotten so bad that I am ignoring any build errors that come from those distros and telling the reporters to switch to some source that adheres to the philosophy that the kernel version determines the API. Larry -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 05/01/2015 09:46 PM, Stephan Kulow wrote:
Am 01.05.2015 um 14:08 schrieb Jan Engelhardt:
On Friday 2015-05-01 13:20, Stephan Kulow wrote:
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-) It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE. Before it's misunderstood: the 3.16 kernel in 13.2 is maintained as long as 13.2 is - replace 3.16 with 4.$SOMERANDOMNUMBER in my argument :) The point is that there are features that you cannot backstep from. For example, kernelnewbies.org says about 3.16: "In this release, XFS has added a btree that tracks free inodes. This feature adds does not change existing on-disk structures, but adds a new one that must remain consistent with the inode allocation btree; for this reason older kernels will only be able to mount read-only filesystems with the free inode btree feature."
Whatever kernel is picked for 13.3, if it is less than 3.16, people could run into a problem for something that worked before. I have not found the new flags on my XFS superblocks yet, but that does not have to mean anything.
Can we agree on: 13.3 kernel needs to be able to cope with filesystems created with 13.2
and leave out version numbers?
Greetings, Stephan
Out of interest would the maintenance burden be much less if openSUSE 13.3 used one of the upstream LTS kernels, then only applied the SUSE specific patches (as opposed to bugfix / driver updates)? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sat, May 02, 2015 at 09:48:36AM +0930, Simon Lees wrote:
Out of interest would the maintenance burden be much less if openSUSE 13.3 used one of the upstream LTS kernels, then only applied the SUSE specific patches (as opposed to bugfix / driver updates)?
It depends on what you compare with. It would be less work than picking relevant patches ourselves and essentially maintaining our own stable branch. But more work than reusing the work already being done for SLE kernel (which, btw., is what Evergreen 11.4 does and what is/was the plan for Evergreen 13.1). Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 1 May 2015 at 14:08, Jan Engelhardt <jengelh@inai.de> wrote:
The point is that there are features that you cannot backstep from. For example, kernelnewbies.org says about 3.16: "In this release, XFS has added a btree that tracks free inodes. This feature adds does not change existing on-disk structures, but adds a new one that must remain consistent with the inode allocation btree; for this reason older kernels will only be able to mount read-only filesystems with the free inode btree feature."
Whatever kernel is picked for 13.3, if it is less than 3.16, people could run into a problem for something that worked before. I have not found the new flags on my XFS superblocks yet, but that does not have to mean anything.
I have already tested this. The current SLES 12 kernel can *already* support opensuse 13.2 XFS volumes SUSE do not ship 'vanilla' kernels (or other components) with SLE. They spend a lot of effort adding/backporting features - I think we to stop thinking the version number is a good indicator of a packages capabilities.
- kernel and glibc shall be refreshed for releases.
Why? Any technical reasons or just so?
No technical reasons, just practical ones. Sometimes there is new clunky hardware that needs something that is not 2 years old. Or because they made working with btrfs more endurable (fast device replacement in e.g. 3.19) for everyone. I kind of like how gcc does its multiversioning: it allows you to optionally install a newer one _from the same repository_. That one may be an unmaintained Tech Preview, but that would be good enough for me. The only issue is that kernel-*s share the same package name while gcc does not, so that has some implications how OBS selects them for build :/
See my above comment - I think we need to check what the sources we have now can actually DO before judging whether they do what we want.. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
participants (7)
-
Jan Engelhardt -
Larry Finger -
Michal Kubecek -
Richard Brown -
Robert Martens -
Simon Lees -
Stephan Kulow