Proposal for revitalizing the sponsorship process for packaging

Michael Schwendt mschwendt at
Wed May 2 10:56:34 UTC 2012

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

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  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

So-called "stalled reviews" don't "block" anything:
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

More information about the devel mailing list