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
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