On 21/01/15 22:15, Matthias Runge wrote: > On 21/01/15 11:49, Nikos Mavrogiannopoulos wrote: > >> I don't have a solution to bring extra resources to reviewing (which >> will be the ideal), but I'd like to propose an amendment to allow >> bringing packages even if no reviewers are available (the typical case). >> >> Step 6: ... If the proposed package is not reviewed for 2 months, the >> package must be reviewed by the submitter, and a git module with the >> master branch will be approved. Open slather is probably not ideal. Perhaps we could formalize a multi-level reviewer approach... eg. I've done pre-reviews and reviews, picking up various items. But then someone who actually knows what they are doing in writing specs for Fedora often kicks in a makes lots of suggestions / points out issues. So for me, I'd be happy to pre-review packages, but I'm not confident that: - I'll pick up anything / everything - I quite often don't have much experience with a particular build system or source language. So again, I miss the "easy" way to get it to build properly. - To give a final OK/Accept on a package. I'd prefer for a more experienced packager to make that call. - License checking is difficult to understand. - I'm not keeping up with continued packaging guidelines changes. Hence: I propose creating groups of packagers/wiki pages with expertise in: - language specific area, eg Python. - build system specific, eg cmake. - licensing checking,. - package accepters. However, I get rather annoyed when I try to build a spec/srpm, and this doesn't work at all. Is there a possibility that we can have a review request with retrievable .spec and .srpm automatically be build in mock (current/previous/next release) and respond with build success/failure back to the review request bug. The submitter would then immediately know that they have BR/R issues to resolve (and that they probably should have built in mock before submission). Dave. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
