Hello team! As you might recall Tomas Chvatal did a complete refresh of python in openSUSE Leap 15.2. This was done out of his initiative and I recall that it took him at least two months to get that done. openSUSE Leap 15.3 is based on SLE 15 SP3 binaries. SLE 15 SP3 is not really a feature release, if we keep these releases in sync, nobody really expects any revolution. So I do not expect the same refresh in 15.3, but we'll welcome update requests. However, SLE 15 SP4 will be a different story as it's the feature release (Tick-tock model). I do expect to have a slightly lower volume of changes compared to SP2 since we're further in the product lifecycle. I'd still appreciate if we could update as much of the Python ecosystem as we can. Closing the Leap Gap (CtLG) will require that some packages have to be accepted first in SLE, so because of that, the rebuild cycle will be longer. And SLE submission will have to reference some feature tracker. openSUSE Release team will support you on the way just like we supported Tomas but we will need a lot of help and coordination from your side. Do you see this as a doable goal for Leap 15.4? If you'd like to split the entire effort, then Leap 15.3 is still Alpha until 17th Feb, so we have quite some flexilibility there. Not so much for SLE part of Leap as SLE has already Beta3. ps: I did previously talk with Kristyna Streitova on this topic and the outcome of our conversation is this email. -- Lubos Kocman Release Manager openSUSE Leap SUSE LINUX, s.r.o. Krizikova 148/34 tel: +49 173 5876850 186 00 Praha 8 http://www.suse.com Czech Republic
Hello! On 1/18/21 5:40 AM, Lubos Kocman wrote:
As you might recall Tomas Chvatal did a complete refresh of python in openSUSE Leap 15.2. This was done out of his initiative and I recall that it took him at least two months to get that done.
Does "refresh" refer to the Python packages, the interpretor or both?
However, SLE 15 SP4 will be a different story as it's the feature release (Tick-tock model). I do expect to have a slightly lower volume of changes compared to SP2 since we're further in the product lifecycle. I'd still appreciate if we could update as much of the Python ecosystem as we can.
Closing the Leap Gap (CtLG) will require that some packages have to be accepted first in SLE, so because of that, the rebuild cycle will be longer. And SLE submission will have to reference some feature tracker.
Isn't that going to delay updates in Leap considerably longer? My personal experience with SLE submissions is that they tend to take much longer than Leap submissions due to the necessary QA steps involved. Adrian
On Mon, 2021-01-18 at 09:56 +0100, John Paul Adrian Glaubitz wrote:
Hello!
On 1/18/21 5:40 AM, Lubos Kocman wrote:
As you might recall Tomas Chvatal did a complete refresh of python in openSUSE Leap 15.2. This was done out of his initiative and I recall that it took him at least two months to get that done.
Does "refresh" refer to the Python packages, the interpretor or both?
However, SLE 15 SP4 will be a different story as it's the feature release (Tick-tock model). I do expect to have a slightly lower volume of changes compared to SP2 since we're further in the product lifecycle. I'd still appreciate if we could update as much of the Python ecosystem as we can.
Closing the Leap Gap (CtLG) will require that some packages have to be accepted first in SLE, so because of that, the rebuild cycle will be longer. And SLE submission will have to reference some feature tracker.
Isn't that going to delay updates in Leap considerably longer? My personal experience with SLE submissions is that they tend to take much longer than Leap submissions due to the necessary QA steps involved.
Well keep in mind that even in Leap 15.2 updates to packages with SLE origin had to be submitted from SLE-side. So I don't see much of a change to be honest. We used SLE workarounds for temporary forks and such approach would be doable even today while keeping packages forked in openSUSE:Leap:15.3 project, but in general we should avoid it.
Adrian
-- Lubos Kocman Release Manager openSUSE Leap SUSE LINUX, s.r.o. Krizikova 148/34 tel: +49 173 5876850 186 00 Praha 8 http://www.suse.com Czech Republic
Hello! On 1/18/21 11:09 AM, Lubos Kocman wrote:
Well keep in mind that even in Leap 15.2 updates to packages with SLE origin had to be submitted from SLE-side. So I don't see much of a change to be honest.
Yes, I'm aware of that. But if I understand correctly, updates now always have to go through SLE if the package exists both in SLE and Leap. Before that, we could update packages either in SLE or Leap, couldn't we? My fear is that some Leap users may find the update cadence for individual key packages too slow. The original idea of Leap was to have a SLE base but with key packages like Firefox being kept up to date. Adrian
On Mon, 2021-01-18 at 11:18 +0100, John Paul Adrian Glaubitz wrote:
Hello!
On 1/18/21 11:09 AM, Lubos Kocman wrote:
Well keep in mind that even in Leap 15.2 updates to packages with SLE origin had to be submitted from SLE-side. So I don't see much of a change to be honest.
Yes, I'm aware of that. But if I understand correctly, updates now always have to go through SLE if the package exists both in SLE and Leap.
Before that, we could update packages either in SLE or Leap, couldn't we?
So the change of origin required an an approval of Release Team member. Generally packages with SLE origin were really updated through SLE. The project SLE Workarounds was usually holding fork only temporarily, until the request got into SLE. The effort was to have sources as close as possible. So I would not say that there was an intention to diverge. I see that 15.2 already disappeared from http://tanana.suse.de/, but if there was a source divergence it was reported as feature against SLE. There was about 11 of them. The way I see it as that before we were waiting for sources from SLE, that we could temporarily fork in order to resolve build issues. Now we're waiting for binaries that we can also temporarily fork if it blocks larger amount of submissions. We'll try to have up2date version of everything in backports. Which is where our focus should be
My fear is that some Leap users may find the update cadence for individual key packages too slow. The original idea of Leap was to have a SLE base but with key packages like Firefox being kept up to date.
Adrian
-- Lubos Kocman Release Manager openSUSE Leap SUSE LINUX, s.r.o. Krizikova 148/34 tel: +49 173 5876850 186 00 Praha 8 http://www.suse.com Czech Republic
Lubos Kocman píše v Po 18. 01. 2021 v 04:40 +0000:
openSUSE Leap 15.3 is based on SLE 15 SP3 binaries. SLE 15 SP3 is not really a feature release, if we keep these releases in sync, nobody really expects any revolution. So I do not expect the same refresh in 15.3, but we'll welcome update requests.
I wonder what we can bring new to SLE. The biggest thing which we created right now in Factory is coinstall Python (i.e., ability to have all python-* packages in multiple versions). Originally, we thought it would be the nice feature to have for SLE (so that we have not only plain interpreters, as we have now with python39, python36, and python27 packages, but whole sets of all Python packages in those versions; of course, if the package supports particular version of Python, that is). However, I cannot find any Jira which would be appropriate for it. Otherwise, we have all repositories on all distributions synchronized, so upgrades and changes in Factory could be easily promoted to any SLE.
Do you see this as a doable goal for Leap 15.4?
Synchronization of other packages is completely case by case. Sometimes, we just cannot upgrade, because in SLE we have so ancient version, that we cannot guarantee smooth upgrade of configuration to the newer version. And of course, not all packages are so synchronized across the distributions. Which exact packages we are talking about? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Everything you were looking for was right there with you all along. -- The Wizard of Oz
On Mon, 2021-01-18 at 21:24 +0100, Matěj Cepl wrote:
Lubos Kocman píše v Po 18. 01. 2021 v 04:40 +0000:
openSUSE Leap 15.3 is based on SLE 15 SP3 binaries. SLE 15 SP3 is not really a feature release, if we keep these releases in sync, nobody really expects any revolution. So I do not expect the same refresh in 15.3, but we'll welcome update requests.
I wonder what we can bring new to SLE. The biggest thing which we created right now in Factory is coinstall Python (i.e., ability to have all python-* packages in multiple versions). Originally, we thought it would be the nice feature to have for SLE (so that we have not only plain interpreters, as we have now with python39, python36, and python27 packages, but whole sets of all Python packages in those versions; of course, if the package supports particular version of Python, that is). However, I cannot find any Jira which would be appropriate for it.
I've mentioned SLE 15 SP3 only because Leap 15.3 is in fact re-using SLE-15 SP3 binaries. So any changes to Leap/Backports/PackageHUB (nowadays all three are essentially the same) are also dependent SLE sources and nowadays also binaries. My interest is mostly on the Leap- exclusive part (Package Hub for SLE). No Jira exists for Leap 15.2, that was done completely out of jira. I can definitely create jira for SLE-15-SP4 that can be tracking both Leap and SLE part.
Otherwise, we have all repositories on all distributions synchronized, so upgrades and changes in Factory could be easily promoted to any SLE.
Do you see this as a doable goal for Leap 15.4?
Synchronization of other packages is completely case by case. Sometimes, we just cannot upgrade, because in SLE we have so ancient version, that we cannot guarantee smooth upgrade of configuration to the newer version. And of course, not all packages are so synchronized across the distributions.
Which exact packages we are talking about?
No specific packages. If there would be a request to update particular package, then we'd track it separately. This is more of a holistic request to have up2date python ecosystem in Leap 15.3.
Best,
Matěj
-- Lubos Kocman Release Manager openSUSE Leap SUSE LINUX, s.r.o. Krizikova 148/34 tel: +49 173 5876850 186 00 Praha 8 http://www.suse.com Czech Republic
participants (3)
-
John Paul Adrian Glaubitz -
Lubos Kocman -
Matěj Cepl