Re: Proposal for revitalizing the sponsorship process for packaging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux