On Wed, 02 May 2012 08:55:22 +0200, AL (Alec) wrote: > I sort of like the "submit a provisional spec" approach. It will qualify > the requests, and the requester will get some basic understanding making > future communications with an upcoming packager easier. And, of course, > there will be users out there using the provisional package. There might > even be feedback. If not packaged correctly, there might not be any feedback at all. Imagine a broken/empty -debuginfo package which would make ABRT fail. Truth is, in case of problems, many users would rather install from source tarball (or a 3rd party repo) than visit bugzilla to submit a bug report _manually_. For broken dependencies -- imagine the worst-case scenario of a new package not being installable at all (and it happens that its packager doesn't notice -- it's pretty common to ask in message boards, but not react when somebody suggests filing a bug report. It is equally common for users to assume that the packagers notice a problem themselves. Even if after several weeks a problem still is reproducible, a user doesn't submit a bug report. I've made several experiments, pointing users at the convenient http://bugz.fedoraproject.org/PACKAGE-SRC-RPM-NAME page for easier entry into bugzilla, and more often than not they would find an excuse for not submitting a bug report nevertheless. > Actually, I know examples of Great Applications which are now sitting in > review queue submitted by people who are not likely to become packagers > - the barrier is too high for them. This creates an extremely bad > situation. The submitter eventually drops off, with the feeling that > Fedora is... well, nothing nice. And the application becomes "blocked", > since no other packager can "take over" the request. What makes you think so? Where did you read that an "application becomes 'blocked'"? So-called "stalled reviews" don't "block" anything: http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews However, activity from a submitter/packager and a reviewer is needed. > Actually, I know examples of Great Applications [...] As "Great" as an application may be, if there are no volunteers to do the packaging, the testing, the long-term maintenance, the handling of bug reports, a fundamental problem cannot be solved. A dumping-ground for poorly maintained (or unmaintained) packages bears much more risks than offering potential. Those who remember the ancient "Red Hat Contrib" know the server full of aging src.rpms with questionable benefit. With the current process, when the first user feedback arrives (especially in bugzilla), a packager may _have to_ consult existing documentation on packaging (in order to apply patches and fix packaging bugs), on using the Fedora Build System and the Updates System. You can skip reading that documentation during the review process, but suddenly a new hurdle is discovered when the first package update is needed. Sponsors exist to help the sponsorees, but they cannot guarantee that a packager drops off nevertheless. It doesn't scale to add lots of new packages without adding new contributors for them. Remember, you can contribute to Fedora in several ways, not just low-level packaging. Everything would be better, if more users were brave enough to help with bug-triaging, be upstream liaison, be update/release master, to name a few tasks that I could think of. And if a working src.rpm exists, updating it to include a newer tarball isn't rocket science anyway. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64 loadavg: 0.00 0.04 0.05 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
