On 21 July 2017 at 19:08, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Don't get me wrong, I'm not saying this can't work or work well, I saying from a distro standpoint it does not provide any clarity on what user can expect. Users cannot expect a TW made up of released packages if the maintainers, in their discretion, can provide upstream betas instead.
What is the old Demming philosophy of TQM (total quality management) -- "if you can't measure it, you can't manage it." Whatever the maintainers decide is a difficult ruler to measure against.
And that is why the trust in our maintainers is only part of the equation Another part is hundreds of openQA tests doing human-like manual installation, upgrades, application tests, etc, making sure that at least the basics which are maintainers do never break You could argue that we "trust, but verify". And while of course this verification is not 100% coverage and will never find 100% of bugs before we put them in the hands of users, it has very measurable benefits. We can all but guarantee that Tumbleweed is always in a usable state. We KNOW installation, upgrades, and basic application functionality works. We can be reasonably confident that it works on most hardware. That means that most bugs that slip through are 'shallow' and easily fixed. Even if that is not true, because a large number of bugs are caught by openQA before reaching users, when something does get caught outside of openQA, it's an easy decision matrix for our maintainers to prioritise - real bugs found by real humans in the real world are almost certainly going to get handled first before something obscure that openQA caught and no user will see because openQA caught it. This helps keep our maintainers from being overloaded and reduces bug resolution time for users. And then of course, last but by no means least, we are always improving openQA's coverage so we catch more more often, meaning it is a constantly improving system. I don't think we could trust our maintainers as fully as we do if we didn't have such a robust system of automated QA to provide that verification - and even if we did, I fear they'd be overloaded as a result of their own successes. This would lead to the kind of thing I see in Arch, where the distribution artificially delays updates (like GNOME) so they can cope, wereas our model allows us to ship major GNOME releases within hours of their release, without breaking our users systems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org