How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)

Michael Schwendt mschwendt at gmail.com
Fri Feb 13 21:48:59 UTC 2015


On Fri, 13 Feb 2015 16:40:25 +0000, Ian Malone wrote:

> >    -> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
> >
> > Submitting a new package is just _one_ of multiple ways to find a sponsor,
> > since it is an opportunity to demonstrate that you know packaging.
> >
> 
> Thanks. I think when I'd looked at it I'd discounted the review and
> comment on others' submissions process as it would seem to require you
> to have a better idea of what you're doing than the person submitting
> the package,

Why would you believe that?

If the wording of some document is misleading/ambiguous, it would be
an idea to fix that.

There is no requirement for reviewers to know more about a package than
the submitter. It's certainly not a MUST or SHOULD item in the review
guidelines.

Even for the person doing a full review there are only vague requirements
wrt runtime testing: "SHOULD: The reviewer should test that the package
functions as described. A package should not segfault instead of running,
for example."

And let's not forget: the submitter ought to do a self-review of the
package anyway before adding it to the review queue. It's *not* the sole
responsibility of the reviewer to perform all the reviewing, especially
not the more difficult checks (not limited to licensing and checking for
legal issues).

> and potentially just creating noise when other people are
> looking at it too.

For new packagers not doing full reviews, it can be a brilliant idea to 
apply their own sanity checks when skimming over a spec file *or* to
examine random items mentioned on the review guidelines page. It's a
good way to gain experience. In cases where you find nothing to be
wrong, it can be helpful to explicitly acknowledge important details
that are packaged correctly, rather than only hoping to find mistakes.

However, from time to time the sponsors meet people, who are not only
afraid of making mistakes, they are also afraid of asking questions.
It's unlikely such people are brave enough to comment on review
requests in the queue.


More information about the devel mailing list