Network setup of builders

seth vidal skvidal at
Tue Jul 2 02:58:37 UTC 2013

On Thu, 27 Jun 2013 10:17:00 -0700
Toshio Kuratomi <a.badger at> wrote:

> > 3) Projects which want to offer release for different platform than
> > Fedora/EPEL. E.g. Suse, but I would count here even Software
> > Collections, Secondary Architectures.
> -1  Software Collections perhaps, but the other uses are out of
> scope.  Secondary arches, for instance, require copr-be hardware for
> the arch to be available.

Which, in the case of arm, rumor has it - we will have access to (in
one way or another).

> > 4) Repos which should be private for some reasons (embargoed builds
> > which should be tested)
> > 
> +0 -- I think this is out of scope but I suppose the scope could be
> expanded to encompas it.  I'm a little leery of it though.... Part of
> what makes the legal ramifications of copr work is that we're
> crowdsourcing the monitoring of what's being hosted in coprs.  Having
> private repos eliminates that check.

Private repos has been specifically requested by various powers that be.

The gist of the private repos is to allow someone to build something
and put a password on the repo to restrict access to it. That's really
all. So think of it less as a 'private' repo and more as a 'not public'

I can definitely see the advantage of being able to build something in
a copr with a password. Email the password out to a mailing list of
people and tell them to go test it. Not for purposes of keeping it
private but to keep it from being stumbled upon, either b/c it is not
ready for public consumption or b/c you are worried it might eat babies.

Otherwise I agree with the scopes you outlined.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <>

More information about the copr-devel mailing list