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.