Improving our processes for new contributors.
mschwendt at gmail.com
Mon Jul 20 22:55:01 UTC 2015
On Mon, 20 Jul 2015 17:34:09 +1000, Nick Coghlan wrote:
> Don't underestimate the explanatory power of worked examples
Don't underestimate them how? I fail to see what your response has to do
with the paragraph from my mail you've quoted.
Some of the current (and past) problems with the review queue:
- There are more new contributors waiting for a sponsor than sponsors
working with those people to turn them into Fedora packagers.
- There are poorly made packages in the queue. Sometimes even submitted
by approved packagers. Even in dist git there are packages, which would
not pass review anymore. In other cases, reviewers have made mistakes,
- A growing number of new contributors submit only a single package,
which is very limited input for a sponsor to review, especially if the
single package is flawed. Sometimes it's a library API, and a year
later there's still no package using that API => adding a package
to Fedora's package collection won't make new API users pop up like
- A growing number of new contributors prefers waiting for something
to happen instead of following the recommendations and attempting at
doing a few reviews.
- A growing number of [new] contributors do something completely
different than how it has been done for many years, ignoring common
practice. This is problematic for potential sponsors and/or reviewers
as the packaging guidelines are complex but never complete.
You cannot fix this with more detailed guides, "worked examples". The
opposite might happen: It could be that more beginners would manage to
submit a package following examples in trial-and-error fashion, but the
real "fun" starts as soon as the first bug reports are submitted.
Handling bug reports and releasing updates cannot be simulated well
> [...] aimed at
> the relatively common cases like "I want to take an existing PyPI
> package with no dependencies other than Python itself, propose adding
> it to Fedora, and keep it up to date as upstream make new releases".
An attempt at creating package-monkeys?
Turning upstream releases into RPM packages is something that literally
asks for automation. On the contrary, maintained packages is what adds
value to a package collection: responding to bug reports, debugging,
bug-fixing, forwarding [enhanced] bug reports to upstream, observing
upstream activity/commits/communication, integration testing, ABI/API
stability, handling FTBFS issues. That involves a lot of stuff you cannot
cover in documentation specific to Fedora. Or you can try to, but it will
reach the size of a book. Don't hope for more contributors then.
> Unfortunately, the presentation of information at the moment tends to
> focus on the individual steps (e.g. the packaging review guidelines),
> without first providing that larger context of how software flows from
> an upstream project *through* Fedora and into the hands of end users.
??? With all due respect, replies like that are reason to stay away from
this topic. Which target group do you have in mind?
There are various howtos ranging from building a package to submitting an
update, or a page covering maintainer responsibilities and update policies.
Once a person can access Fedora's infrastructure, only few of the approved
packagers run into major problems trying to "release an update" -- unless
a service is down or is affected by bugs.
What Fedora must be careful with, however, is not to flood existing
contributors with new "services" that are too experimental. For example,
AutoQA reports in bodhi that are false positives and manage to confuse
the update submitters. Or, for some time I receive ABRT notifications of
the class "ABRT report for package XYZ has reached N occurrences", and a
bugzilla ticket is missing, and there is no way to ask the reporter to
submit a full report.
More information about the devel