On Tue, 1 Dec 2015 15:49:20 -0600, Ranjan Maitra wrote: > OK, thank you for being "blunt" but my general point is that putting in a package for review is needlessly bureaucratic and does no justice to the volunteers on either side. > If at all, the bureaucracy that could be removed is the review process for packages from existing members of the packager group, who have demonstrated before that they know their stuff. There are some, who could be highly productive and could pipe out a higher number of packages (e.g. needed dependencies), if they didn't need to wait for a second pair of eyes to check even trivial packages. Unfortunately, the review queue (including the needsponsor queue) contains too many examples of people, who just want to dump a package into the package collection without real interest in RPM packaging and maintenance of the package. That isn't anything like a basis for "a distribution" of packages. There must be a little bit of effort with regard to building packages in a sane way as well as trying to respond to feedback from the package users. > For example, creating the spec file (with the evolution that seems to be > happening all the time) could better be automated by some script on a > website. "Could, could, could". That's always the same cheap talk. Over the years there have been various tools to automate RPM packaging *including* determining BuildRequires and explicit Requires. Where is the tool that's sufficiently complete and safe to use? It's still much easier for human packagers to do it right and use custom tools to automate some tasks. > At the very least, have it suggest a skeleton. A skeleton for what? Do you realize how much packages can differ? For example, packages for Java stuff vs. packages for Perl or Python? There's the template generate "rpmdev-newspec" in the rpmdevtools package. It creates a spec file for building and packaging a typical Autotools based program. > Doing so will also leave out extended review discussions. Once a package > is submitted, let it go through rpmlint, etc. (and fix rpmlint to not > warn on nonsensical spelling errors) It's *so* simple to ignore those warnings (where rpmlint fails because of poor dictionaries or related issues). Why do you continue to blame rpmlint for some of its false positives? > doing the automated checks and speed up the process. Have you run the fedora-review tool on your packages and/or bugzilla review tickets yet? > Do you feel that it is productive for an expert to inform a submitter > of basic errors which could have been caught by some auto-checking > mechanism. It's "necessary evil" as long as (1) the package submitters care a lot less about their packages than the reviewers, and (2) there is no tool that can perform fully automated reviews. Some package submitters have the bad habit of disagreeing with tools, either ignoring findings, claiming that the tool is mistaken or coming up with strange rationales if a reviewers asks. > This would reduce their loads. There is much higher load for the submitters, provided that they really want to maintain the package and not only dump it into a repository. Anyone, who thinks that the review process is too high a hurdle, has never practised package maintainance before. Not with personal packages in some private repo, and not with a public personal repo either. Certainly not for a period of let's say a year or so. Or multiple years in RHEL/EPEL-style. Of course, in a personal repo you could create packages in a way that would not only be poorly or wrongly packaged but even "forbidden" at Fedora. > So do you think that packages should be included only if they are in > demand by multitudes? A single reviewer is needed. A single person with interest in the package to build the smallest possible team of two. Either that or "review swapping", which has been advertized/suggested often enough. Yes, it is a major disappointment, if there is nobody else to even post runtime test reports for a new package. And if potential users of the package -- members of the distribution's community (!) -- prefer compiling from source tarball instead without contributing anything. > It sort of defeats the purpose of Linux. Please elaborate. What do you have in mind here? > Ideally, if only two people have need for a package, and if the first > person is the packager (say), then how likely is it for the second user > to actually be a member of BZ and the review set, rather than go off to > some other distribution (AUR, say) where things are easier to come by? Pardon? Do you intend to play the "attempted blackmail" card here? That's quite common for so-called "distro-hoppers", who would switch back and forth between distributions for every pet peeve they come up with. ;-) If there's a distribution doing also everything else better *and* not only offering that certain package that's oh-so-mission-critical for somebody, hey, great! Let's hope it somehow will lead to making the upstream software even better, since often it's easy enough to build from source. Eventually, there will be substantial interest in offering packages and corresponding maintenance. > > For quite some people it is less effort to run with selfmade packages > > in a private local repo than becoming a volunteer package maintainer > > with interest in team work (for example). > > Agreed! But do you want that to happen? You will then lose the ability to > have more software packages then. That smells like the "quantity instead of quality" card. There are hundreds of packages in the collection, which are not used by anyone. They are in the collection, because a _single_ submitter added the packages. Sometimes they don't even work anymore or have never worked well before. Nobody notices, not even the packager. In other cases there are bug reports, but without a response from the packager => users give up trying to use the packages, spend a bit of time on following build instructions and build from source. Eventually, the broken packages are discovered, or the inactive/non-responsive packager is discovered, and somebody needs to spend additional time on cleaning up the mess (such as removing and retiring packages). If you want quantity, start with increasing the number of loyal contributors that will lead to an increase of happy and loyal users, who may become contributors (if a minimum of interest in that is present). > Better to have a stringent but automated process for evaluation: if the > submitter passes all the steps, let his package in or at least put it on > probation. Or put it to the top of the list. Otherwise, if he has > non-standard requirements, send it to BZ. You may want to read up on what controversial plans some people have come up with, such as staging repos, outer and inner rings, playgrounds or dumping grounds for unreviewed packages. Some of the plans may become fruitful, but require that the contributors are willing to leave the dumping ground level by offering a bit more than a src.rpm that seems to build. As soon as some packagers receive a first batch of bugzilla reports from frustrated package users that have started using a package, they hide somewhere. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
