On Mon, 20 Jul 2015 17:34:09 +1000, Nick Coghlan wrote: > Don't underestimate the explanatory power of worked examples -snip- 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, too. - 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 mushrooms. - 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 with Copr. > [...] 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
