On Mon, Mar 28, 2022 at 3:43 PM Stefan Brüns email@example.com wrote:
On Montag, 28. März 2022 20:07:42 CEST Martin Wilck wrote:
On Mon, 2022-03-28 at 18:56 +0200, Richard Brown wrote:
On Mon, 2022-03-28 at 18:53 +0200, Stefan Seyfried wrote:
On 28.03.22 18:50, Richard Brown wrote:
I agree, but this deficiency of Leap should not be addressed by encoraging people to use untested, unreviewed, unmaintained, unsupported, unsupportable software.
I find this statement disrespectful against everyone who maintains software in inofficial repos. Almost all packages in openSUSE started out in home projects and passed through a devel project before eventually being added to the distro. At the end of the day, the quality difference between official and inofficial packages is not as huge as you imply.
The important part is "*started* out home projects". If a package is actually in a good state, there is no reason it can not be forwarded to a devel project and to Factory.
I maintain a lot of packages, and I would not recommend anyone to use the work-in-progress from my home repositories. I use packages from devel projects for testing only, and only because I know what I am doing.
Of course, when you activate someone's home repo, you don't know. The repo owner may be long gone or be a malicious jerk. So no, we shouldn't actively encourage it. But we shouldn't discourage it, either, because we'd be discouraging our distribution as such.
Perhaps some weak "review" process could be established around public, inofficial OBS repositories. For example, a bot could auto-uncheck the "publish" flag for repos that haven't seen any updates for a long time, and users setting the "publish" flag could be asked to provide meaningful descriptions for their repos and the packages therein.
And who will do the review? And if someone does the review and it passes, why not let *everyone* use the result in a straight forward way, and push it to Factory?
We shouldn't be pushing people to 3rd party repos, Period.
OK, so we should advise them to "configure; make; sudo make install" instead?
No, my advice would be not to use Leap, but that's totally getting off topic.
and use ... what? Factory also needs 3rd party repos. Not as strongly as Leap, but it still does. Not to mention that Factory has other disadvantages that simply don't make it suitable for everyone.
Does Factory really need 3rd party repos? I can definitely work without any.
For Leap, the picture unfortunately is a different one. It misses quite some packages, but this is for a large part caused by its quite old core. Many upstream projects have dropped support for GCC 4.7 and Python 3.6 (to name just the biggest two elephants, but there are plenty), and providing up-to- date packages for Leap 15.3/15.4 has become quite hard.
Despite all the hard work done by many contributors, Leap 15.4 is quite old even on its coming release. From a 15.3 perspective it may look good, but from a TW perspective it feels like stone age. IMHO Leap would be in a much better shape if it were Leap 16.0 - but this will probably take another year ...
Btw, the discussion is not OT as long as people claim that simply
ditching s.o.o was a step in the right direction:
Back to the topic at hand though, if discovering 3rd party software from software.opensuse.org is essential for Leap to be useful, that's a problem that needs to be addressed in Leap, not software.opensuse.org
Looking forward to your suggestions how to do that.
- streamline the Leap submission/upgrade process
- rebase the core more frequently
Updating packages in Leap still takes too much effort. For Factory, the process is trivial, update in the devel project, forward, done. For Leap, one first has to find the right target project (Leap vs SLE package). If the Factory package is too new (5 years of changes is not uncommon), one has to find a version which is sufficient, but does not break SLE/Leap. Then after a few months someone may act on the MR. And then you notice the update deadline has passed, the dependencies are updated, but you have no chance of updating the leaf package you wanted to update. Been there, done that.
I don't like Ubuntu, but its core is updated every two years, and that *is* the reference for many upstream projects. When Leap 15.4 is released, people will compare it with Ubuntu 22.04 LTS, and that will be quite unfavorable for 15.4. Upstream projects will mostly target 20.04/22.04 LTS, and the dependencies from Leap 15.4 will not suffice.
To put it bluntly, we rely on SUSE Linux Enterprise product development for openSUSE Leap. While we have made significant headway in adding the community to the process, at the end of the day, it is SUSE's choice on how major and minor version evolution works.
Personally speaking, I think SUSE needs to do what Red Hat has done and come out with a fully defined, predictable schedule so that the community and the company can work more effectively together to drive the future for the SUSE Linux family of distributions.
To note, starting with RHEL 8, RHEL gets new point releases every six months, and new major releases every three years. RHEL 9 is coming in two months, which is three years after RHEL 8 arrived. I'd love something similar for SLE.