On 28 December 2016 at 20:39, Anton Aylward wrote:

On 12/28/2016 12:49 PM, Richard Brown wrote:

...

...

...

I must admit I'm confused here. Regular readers will recall that I make use of the kernel_Stable repository. I'm running kernel 4.9.0.

Why? are you involved in Tumbleweed kernel testing? If not ,then the correct way to consume a new kernel is to wait until it's actually tested and in Tumbleweed properly.

Someone described TW as not factory but a perpetual beta release.

That is not how I would describe it. TW is not Factory, TW is a rolling release. Every single 'release' of the rolling release is only given to users after several hundred installations, upgrades, and other tests have been carried out On several architectures These are not artificial 'some code gets poked by some script' tests, but fully automated human-interaction testing. openQA installs openSUSE using YaST, using various different YaST mechanisms (graphical, ncurses, ssh, etc). openQA installs various different combinations of software, such as GNOME or KDE or XFCE. openQA boots those systems up and checks all the core applications of those desktop environments, by actually opening them and making sure they work, using the same mouse and keyboard and graphics drivers real users would use. 24 hours a day, 7 days a week, thousands of tests a day, and that's ignoring the dozens of tests we do in 'staging' which happens before any new packages even reach Factory and therefore go anywhere near to Tumbleweed. It's a rolling release. It's tested. It works. Maybe not perfectly, but well enough for it's users to rely on it every day, as I do.

In some ways alternative repositories are like that. (That's certainly the way I use Darktable.) In other ways they are things (such as exFAT for reading SDXC memory cards from my camera) that are from other repositories because they are outside the licence that openSuse uses. Hmm a few other things like that, too.

No, it is nothing like that The repositories you use for darktable and other things have no testing - none at all The repositories you use for darktable and other things have no integration standards - Tumbleweed has countless checks, manual and automatic, to make sure its packages are built, and built properly, with sensible dependency configurations and such The repositories you use for darktable and other things have no quality & legal standards - Even ignoring the testing, every Tumbleweed submission is reviewed by at least 3 pairs of eyes before reaching any humans. Licenses are checked to make sure we can legally distribute those packages as part of the openSUSE distribution. Devel projects are for Development. Home projects are for people to do whatever they want in. They MAY have proactive maintainers. They MAY make some effort to do some of the above. But there is no guarantee. And even in those cases of 'well-maintained' devel projects, none of them yet approach even a fraction of the careful engineering, review, and testing that Tumbleweed goes through. And if they did, I think the entire purpose of Devel and Home projects would be undermined - applying all those checks so early in the development process of a package is going to slow things down, and that's not going to help that package or the users who want a package that works.

Some of 'tested .. and properly' might not happen or might not happen soon enough or when you need it. There was a discussion about disk queueing algorithms on this thread recently, the advantage of BFQ, but while its the default in other distributions, openSuse seems reluctant to adopt it. And lets face it, we're slow to keep up with updates to things like systemd as well.

We move at the pace of contributions. There is lots of talk about lots of things. Lets take the two examples you gave. Did anyone actually submit a proposed change to BFQ as a default? If yes, then you have a point and I & the rest of the openSUSE Board would be interested in following that up. But I believe the answer to be no, and so your point is not valid. Contributions matter, not talk. Same for systemd - systemd is moving at the pace of comfort for our current systemd maintainers. If others are prepared to do the work to move faster, I'm sure we could find an accommodation between new faster-moving contributors and the current one..but talking about wanting a faster moving systemd is all for nothing is no one is stepping up to do the work, and I don't see anyone at this time. Hope this helps -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org