On Mon, Oct 19, 2015 at 5:31 PM, Richard Brown
On 19 October 2015 at 22:02, Claudio Freire
wrote: On Mon, Oct 19, 2015 at 4:38 PM, Richard Brown
wrote: On 19 October 2015 at 21:14, Claudio Freire
wrote: While addon repos have indeed been dodgy regarding stability, they have been very valuable, so your assessment seems quite nearsighted.
Yes, it's difficult to make them hold to the same standards as stable distributions. But unlike rolling distributions, you don't have to risk your whole system (and time) to update some component you absolutely need.
I'd argue my opinion isn't nearsighted, I'm speaking from the school of experience.
I've seen it both as a user and as a maintainer. I've done the 'rolling stuff ontop of a stable base' as a user of old-Tumbleweed I've been part of the team that built repos for that scenario with GNOME:Stable repos (which I also used)
I would put gnome in the same bucket as Mesa, though. So your experience, I'd say, is heavily biased towards the "not worth the effort" portion of packages.
Okay, but then, if you're defining it as the 'very end of the tree' leaf packages..lets say, stuff like LibreOffice?
Well, Libreoffice in *SLE 12* is moving from 4.whatever it ships to 5.0 in a *maintenance* update soon.. which is why it's been so easy for us to throw it into Leap so late ;)
And I dont know what Wolfgang has planned for Firefox, but I guess the point is, we already have a policy of allowing packages at that 'end of the branch' to be updated as part of the regular maintenance of our distributions, both in former releases of openSUSE, also in SLE, and so I suppose no reason to think we won't also do it in Leap.
So, if your limiting your scope to just those sort of packages, you just need to persuade the maintainers to push the changes as maintenance updates..which should be easy to do, its less work for them than building and maintaining whole new repos at least ;)
In that sense I guess you're right, but maintainers haven't been doing that. Perhaps, as you say, they should just do that.
OpenQA only does basic testing, you'll have to recognize, some things depend on people testing, and some use cases get none of that.
openQA does pretty damn advanced testing, and I challenge you to find something which openQA absolutely cannot test. Multi machine, multipath, HA, real hardware, you name it, openQA can do it, or we want to find a way to make it do it.
The biggest limitation is not the technology, but that someone has to care enough about an issue to write a test for it
That's not that hard to do - https://github.com/os-autoinst/openQA/blob/master/docs/WritingTests.asciidoc
And there is lots of examples to learn from - https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/tests
Even when there's the technical possibility of testing, it's not always done. See what's happening with i586. You really think if someone wrote a few thousand tests covering every workflow for the top 90% of users, it'd actually be run? There would probably not be enough resources to do that amount of testing. And nobody did write that many tests. And no, it's not that easy. I read OpenQA test scripts and they read like chinese to me, and I consider myself quite capable of reading code in any language. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org