What will be COPR?

Miroslav Suchý msuchy at redhat.com
Wed Aug 14 17:22:22 UTC 2013

as I started working on COPR I gathered dozens requirements, which does 
not fit into current COPR architecture and I make little step back and 
thought about COPR and what we can have.

This is current options:

1) Continue with current code.
Pros: We can have working (and public) solution very fast (aprox. ETA +1 
Cons: It will be very simply. I will probably have very few time for 
coding RFE so implementation of all RFE will take ages (well years 
probably). Very young code (with all its implication).

2) Merge current code with Koji as backend
Pros: We will use mature code of Koji
Cons: It will be even more time consuming than option 1. So it will 
probably mean start with option 1) and then during several months (I 
estimate it to year or even more) get needed changes in Koji and glue it 
together with COPR. Therefore even less time for RFE.

3) Use Open Build Service
Pros: Mature code with already big community. Can be set up relatively 
quick (ETA 5 months). Lots of feature that neither Koji have.
Cons: different workflow and tools than we are all used to. It does not 
have some features which Koji have.

Obviously there is no right choice. Each option have its pros and cons.

I would love to hear which option you do prefer.

Miroslav Suchy,
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys

More information about the copr-devel mailing list