Packaging review guidelines clarification

[Josh Boyer]

On Thu, 2006-02-16 at 18:12 +0100, Thorsten Leemhuis wrote:
> Am Donnerstag, den 16.02.2006, 17:45 +0100 schrieb Nicolas Mailhot:
> > Le jeudi 16 février 2006 à 09:30 -0500, Josh Boyer a écrit :
> > > > On 2/16/06, Paul Howarth <paul at city-fan.org> wrote:
> > > > there was a discussion at somepoint about scratch build trees in the
> > > > buildsystem to help with update builds.
> > > +1
> > +1
> 
> Enough votes ;-) I like the idea also and added it already to 
> http://www.fedoraproject.org/wiki/Extras/Schedule/IdeasContainer
> 
> I put things like this there where I agree that they should be done for
> fedora-extras sooner or later.
> 
> I'm also willing to put it on the FESCo Schedule -- but first I'd like
> to have someone who drives this whole thing forward. Means: Ask dcbw and
> the other buildsys people (skvidal,?) if this is is possible in general,
> what is needed to get this running, help with doing the work that might
> be needed, report and discuss details with FESCo and fedora-extras-list
> and organize all other stuff that might show up to realize this idea. 
> 
> Any volunteers? No, it does not have to be someone from FESCo. Everybody
> interested in this task can work on this.

Ok, I did some digging in the plague code this morning.  It seems that
plague 0.4 already has support built into it for a testing/scratch repo.
Namely, if the target is said repo, it changes the status of the build
job to done after building and skips the addtorepo step. (Unless I read
some code wrong).

So... it's more a question of can we enable this on the FE buildsys and
if so what method should we use?  Some options:

1)

Plague has the ability to allow building from an SRPM itself.  We could
allow folks to specify the SRPM for a package which will then be
uploaded and built on the scratch repo.  I believe this option is
disabled at the moment on the server config side of things.

Doing this would help people ensure that new packages build correctly on
all arches, etc before actually being imported into CVS.  The idea is
that it'll catch some things that a simple review wouldn't and help
fixup the package that much earlier.

2)

Enable the scratch repo and add a 'make scratch' target to the
makefiles.  Same advantages as above, just that it requires the package
to be in CVS already.

The issues with both of these options are: how do we make sure scratch
builds aren't holding up real builds (or if that will even be a problem)
and if option 1) is used, are there security issues at all with allowing
people to upload SRPMs directly.

josh