Hi, On 07/31/2013 07:36 AM, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Jos Poortvliet
: On Wednesday 31 July 2013 04:42:29 Marguerite Su wrote:
d) Too few people actually care and fix problems of importance Coolo has made some improvements in the past: he emails us/our mailing
On Wed, Jul 31, 2013 at 4:37 AM, Stephan Kulow
wrote: lists. But a lot of packagers are just hit-and-run people. They don't even join the ML. They don't even read coolo's email. They just think: anyway I submit the package, it should be your responsibility to maintain it.
That's bad. We're the distribution which has the most packages, while we're also the distribution which has the most unmaintained packages.
Perhaps, at least, we could improve the integrated automated tests to make sure that pushing things that break other things will simply be impossible...
Careful with this idea: an orphaned package could stop any kind of evolution happening.
Think about stuff that breaks with a new compiler where nobody really cares for; we could a) not push the new compiler, as it 'breaks' other stuff b) drop the stuff that breaks
Now of course, none of the two variants can be blindly applied at any moment (or we would have lost zypper with the update to gcc 4.7 :) )
means of identifying 'orphaned' packages are much more important here in my opinion... each package has a maintainer assigned, no? Are those maintainers 'still around'? Do they still care for the package?
Might be worthy to come up with a list of 'potentially orphaned packages', contact the respective maintainers, if no reply, 'put it up for grab or delete it'.
Yes, this is also important and was part of the discussion we had last year about the maintainer model and project maintainers. I did write a script to collect this data, but as I need an http request for every package that's in Factory the data collection is not reliable as the server gets hit with a lot of requests in a short period of time. There's a FATE request (#314959) for OBS to provide the info I am after in a single request. This will make data collection more reliable and thus feasible. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org