I really don't get all the push back on this. The proposal has absolutely nothing to do with package quality or reliability. If people were using said repos in previous release they already take the "risk" as some people see it. Nothing changes when they upgrade to new point release of distro. All the original author was asking for was automation of a mundane repeated task...ie exactly what automation is for. As far as build errors, that again was not the question. For many repos that are not integrally tied to the core distro (ie not yast, etc) they'll almost never have issues and either way as the original author pointed out the only way to know is to try it. Seeing what build errors there are makes it a lot more likely for drive by contribution. Scenario: John needs packages from devel:somelang, but there is a build error due to newer version of gcc with an easy to apply upstream patch or flag. John files pull request and maintainers simply review (and see builds passing in John's branch). Everyone benefits, rather than maintainers waiting until they need/want the packages or someone pesters them. The whole point here is we have computers...they're already setup...they can check if the packages compile/build..why not let them? In order to make everyone happy (for those who feel there is some implied contract by enabling repos) make it an opt in or better yet an opt out feature. Either way it should be highly encouraged. This was a simple request and as I've seen many times on this list people get caught up on a lot of non-relevant side-topics. Especially given this heavily plays into power-users testing out new releases it should be considered. -- Jimmy On Wed, Nov 11, 2015 at 6:31 AM, Luca Beltrame <lbeltrame@kde.org> wrote:
Il Wed, 11 Nov 2015 11:08:26 +0100, Johannes Meixner ha scritto:
Do they only local builds only on their local computers?
No, but given the number of people involved (contributing) the best we could check was to ensure that packages would build correctly.
But things break every now and then in devel projects, in particular when we land betas of new KDE software that need packaging adjutsments (I killed my own mail access once or twice due to missing buildrequires).
"Leap_43_alpha" the maintainers of "something_useful" could see early if their "something_useful" packages fail to build for "Leap_43_alpha".
That is, if there are reports of said breakage (few tested stuff when the Plasma 5 move was announced).
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org