On 19 October 2015 at 22:02, Claudio Freire
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 ;)
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
Maybe addon repos are only for knowledgeable users, since I happen to be one of those, and I prefer a small, known set of potential problems (up 1 package), to an unknown, potentially large set of problems (dup). It does hinge on me being able to predict that first, small set of potential problems, so it does require knowledge.
Maybe, but I'm trying to talk from wisdom and experience here, not knowledge I can agree with you that addon repos SHOULD be a viable option. But I can also very clearly state that I've seen that tried for enough years to strongly advocate for alternatives, because just because they SHOULD work, doesn't mean they ever have and I haven't seen any reason to believe that they COULD work better now.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org