Jim Walker wrote: > I would like to start discussing the pkg review process as > we apply it to the SourceJuicer automation. > > The current SourceJuicer process is: > - upload a spec file and build pkg > - (optional) edit spec file and build pkg > - review the spec file and vote > - push approved pkgs to /pending or /contrib > > To take better advantage of the SourceJuicer capabilities, > and to address concerns about manifest and namespace > collision issues, I suggest we make the /staging repo > available so both the spec file and the pkg manifest > can be reviewed prior to voting.
So, my under standing of the content of the /pending and /contrib repos and the role of SourceJuicer in those repos is different from what you describe here. I thought that /contrib was to contain packages that had been tested in some way and blessed by community members. They may not be perfect but are good enough for a 'user'. /pending, then, would be a space that would be a means to get packages into /contrib. A communal place to put packages, good or bad, until they're quality could be determined. So, that makes the SourceJuicer process: - upload a new spec file - create review thread - package is built from spec - package published to /pending - go through review and resubmit loop - package gets votes - package is promoted to /contrib > > In addition, at least for the /contrib repo we may want to > require some sanity testing using the /staging pkg prior > to publishing. We would then need to make the two /staging repos available to everyone and replicate the review tool in between /staging and 'real' repos. Even if we do do this, which I'm not suggesting that we do, what would then be the distinction between /pending and /contrib? What would one provide that the other doesn't? _Christian
