Hello, you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory. I considered sending my opinion why but I was afraid it might start a flame without any positive outcome. Recent experience conviced me to try anyway. Disclaimer: the sole purpose of this e-mail is to present my view on the problem and to give responsible people something to think about. It is definitely not meant as a complaint about the particular case (which serves only as an example) or some kind of pointing fingers. Short version: I believe main reason why too many packages never move from home or devel projects to Factory is that on one hand, OBS made it extremely easy to build a package for a set of distributions and even add your own repository with such packages; on the other hand, once you decide to get the Factory, you have to tackle constantly increasing amount of "bureaucracy" to even get the package in and then face a stream of pointless changes in the name of some high standards which are apparently constantly changing and actually not even universally accepted at any given moment. There is a popular phrase about "scratching an itch". The problem, as I see it, is that to scratch one's itch, home project is sufficient. If you are an altruist, you might even push the package into a devel project so that it stands out in the search. But getting it into Factory, that's no more about scratching your itch; you must have really strong motivation for that - and even stronger to do it again once you know what you are going to face. Let's look at an example. Few years ago, I discovered tcpreplay, a set of network utilities which are quite handy when investigating networking issues. I created a package, did my best to avoid OBS warnings and put it into a project under my home so that I could easily install it on my machines. That scratched my itch. Later some guy created a submit request for network:utilities; I checked the package, updated it to new versions, did some cleanup and package ended up in network:utilities. After the December discussion, I decided to submit the tcpreplay to Factory. I checked the build, polished the specfile a bit and submitted it. The request was declined by a check script because a copyright was missing. OK, fair enough, while I don't consider that particular specfile such a great piece of art to need a copyright, why not. I ran the specfile through the spec cleaner service (which often happens automatically with "osc build" but for some reason this wasn't the case). It did some rearrangement and style changes; some I didn't quite like but nothing crucial, so I resubmitted the package. With that submit request still waiting in staging repo, on Sunday I got a request against network:utilities. I didn't have time to review it so I left it to the morning. Before I could do so, 5 hours after creation of the request, to my surprise, it was accepted by the guy who originally poked me to submit the package to network:utilities (but never contributed to the package in any way since). I checked the changes anyway (after all, I'm bugowner so I feel responsible for the package) and I really don't know what to think: https://build.opensuse.org/package/rdiff/network:utilities/tcpreplay?linkrev=base&rev=5 - replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense. - make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it? - replace source files by full URL I don't like this change. More precisely: I hate it. - add "-q" to %setup Why? No idea. - add "V=1" to make Why? To make build warnings harder to see? - break configure line into two If it needed breaking, I would do so. This one had 32 characters... Seriously? - replace ${RPM_BUILD_ROOT} with %{buildroot} The only rule I have ever seen about this was there is no rule. - add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument. - add LICENSE to the package OK, why not. - %files: expand wildcards to explicit lists Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not. - reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes? Summary: lot of meaningless churn, one useful change, two I dislike and two (or two and a half) I really dislike. And a bad feeling that while I took responsibility for the package, I apparently have no say in what should its specfile look like. Don't understand me wrong: I have no problem with reasonable rules, even if they are quite strict (like the tagging policy in our kernel packages or strict coding style policy in kernel networking). But here I feel this crosses a line of harassment. OK, I'll learn to live with it. I'll bite the bullet with packages like firebird or twinkle which are kind of "heart thing". But next time I stumble upon a package that might be useful, I'll think twice before submitting it to Factory. Had I known what was going to happen, well, there would be one less package in Factory (assuming tcpreplay is going to make it). And just today, I got a reaction like "Been there. I know exactly what you are talking about." Sure, you may say that it's my fault I don't understand openSUSE high standards. You might even say openSUSE is not interested in packagers who don't understand its high standards. But you should understand in the end it's always packager's choice if he is going to submit the package to Factory or not. And remember, to "scratch an itch", putting it into a home project is enough in most cases; submitting to Factory is not about "scratching an itch", it's about helping others; things like this work as an active discouragement. Think about it next time you ask yourself why so many packages stay in home or devel project without ever being submitted to Factory. Or, even better, think about it next time you feel urge to completely rearrange a package you are not maintaining (and not going to) just to force your aesthetic criteria on it (and its maintainer). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org