SIGs/Package Review
From FedoraProject
(Need a fancy header)
Contents |
Fedora Package Review SIG
Who Are We?
| Package Review Tickets | |
|---|---|
| New Review Tickets | In-progress Review Tickets |
This SIG is currently in its infancy and things are still being organized.
- Our job is to process new package review submissions and review them for quality and adherence to the Packaging Guidelines. As this is the initial experience for many new contributors to the Fedora Project, we also work towards making this procedure as enjoyable as possible.
(Need a help wanted/qualifications page that doesn't scare off too many contributors.)
Getting Involved
(Need some more structure before we can do much more.)
Scope of Action
- Actually reviewing packages.
- Coordinating reviews of difficult or large packages that may be too much for one person.
- Review triage (ensuring the form of the submission is correct, making sure the package builds and providing rpmlint output).
- Assisting new contributors in doing pre-reviews.
- Investigating modifications to the review process and initial review submission requirements.
- Generating reports and reporting to upstream committees.
Brainstorming
Since we're not yet organized, a communal brain dump can help get us started.
- Should we require (or perhaps strongly suggest) koji scratch builds to be provided with the initial submission? A significant percentage of the packages I look at simply don't build. Tibbs 17:05, 20 August 2008 (UTC)
- Generally recommended IMO. Usually I reject review requests with srpms which don't build on koji with the comment "this doesn't build". However the problem is that this cannot be applied for requests by new contributors seeking for sponsors (currently I give priority over reviewing NEEDSPONSOR blockers). Mamoru 17:30 2008-08-20
- I think it should be required for review requests for contributors that have already been sponsored. bpepple
- Yes. I also think we should ask contributors who are already sponsored to give koji scratch builds with initial submission. Another thing I would like to suggest is to provide rpmlint output on SRPM as well as RPMS for newer package initial submission. This will also save contributor and reviewer's time in package review. -Paragn
- How about providing a review template file less experienced reviewers can download from the wiki and use as a basis for their final formal package review? Petersen 2008-10-03
- This would help people like me who would like to help more (and feel bad about not reviewing nearly as many packages as they submit), but feel like their earlier reviews were dismissed as unhelpful. Konradm 20:52, 9 December 2008 (UTC)
