On 17 July 2015 at 18:17, Michael Schwendt <mschwendt@xxxxxxxxx> wrote: > But else, I don't think this would improve the process for new contributors > significantly. As one can see, the new contributors manage to submit packages > into the queue, and they even point at koji test-builds. One problem is that > a growing number of package submitters stop at that point instead of trying > to follow the process guidelines -- which recommends providing some more things > ahead of time. Don't underestimate the explanatory power of worked examples 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". There's a large number of potential moving parts in that pipeline, from fedpkg, to rpmbuild, to rpmlint, to rpmgrill, to Bugzilla, to dist-git, to Bodhi, to COPR, to mock, to pyp2rpm, to anitya. If you already know what all the parts are, then you can devise your own custom pipeline, but as a new contributor, it would be helpful to have a prescriptive guide that said something like: 1. Generate an initial spec file with pyp2rpm 2. Create a COPR repo based on the initial spec file 3. Register the upstream package with release-monitoring.org 4. ...? Once someone has a visualisation of the end to end pipeline from "upstream release" to "end user installation", and the tasks involved in maintaining a package over time as upstream makes new releases, then that provides a framework to structure all the other tooling knowledge needed to be a good package maintainer, as well as the additional complications that can arise that make it harder to get to a policy compliant package. 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. The language specific sections in the proposed developer portal (https://fedoraproject.org/wiki/Websites/Developer) could potentially cover those simple cases, and then provide pointers to the guidelines for handling the more complex cases. Regards, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
