amending the new package process

[David Timms]

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.