On Friday 15 June 2012 01:22:14 Robert Schweikert wrote:
On 06/15/2012 12:36 AM, Stephan Kulow wrote:
Am 14.06.2012 21:32, schrieb Dominique Leuenberger a.k.a DimStar:
But don't expect that one person can fix all the rest because he's updating one package... you might loose that one contributor taking care of a few packages and being willing to help fix others, if he feels he's *responsible* for all the other failings.
That's actually a very big point here. We already lost contributors because factory-auto does some checks now that require to clean up your spec file.
Well, I do not necessarily feel bad about this. Yes, sometimes the checks in OBS can be annoying, but when the package passes all the checks one ends up with a package that is of reasonable quality. If someone cannot muster the energy to work through the issues I have to wonder whether or not they really want to maintain the package.
Also, more barrier means more sense of accomplishment. More smaller steps (the automated tests and checks) means even more of that so this is not bad, rather good even, I would say.
Now to be honest, our main goal should be to have fun. But this fun applies to all parts, so while it should be fun to update packages (at least to those that can take fun out of it - we're a special kind :), it also has to be working well enough for those that use it.
And I agree. If you can't update glib to the latest upstream version because xteddy maintainer won't act on your mails, fun stops and you take some other activity to spend your work time on. But that's why my first and (so far undoubted) idea was to have more people working on all packages. And these guys then have to fix xteddy to make this whole process work.
I agree, more people at the integration level would be great. However, with the current maintainer model and the way things are presented we would add more people as "maintainers" to each package and the "there are 20 other people to accept the SR" and "there are 20 others to fix the problem" mind set that comes along with very long lists of package maintainers will only be perpetuated.
Later, Robert