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 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

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

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

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 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: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: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:

...

...

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

Am 01.05.2015 um 11:34 schrieb Jan Engelhardt: 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 1 May 2015 at 14:08, Jan Engelhardt 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