On Tue, 2014-04-15 at 15:05 +0200, Miroslav Suchy wrote:
I created first prototype of Playground repo (you know - release
Cool, nice to see some code!
There is an API call to get list of those projects:
(currently undocumented, because I plan to make some changes).
At the time of writing, it gives me "500 Internal Server Error"?
Is this the path we want to follow? Questions? Comments?
As I tried to explain on yesterday's Env and Stacks WG meeting , the
previous steps on defining the Playground repository lead in the
direction of having a real repository (for example, the first paragraph
of  talks about "Repositories/packages successfully built and
satisfying the Playground repository's Policies are copied into the
I think the approach you presented (having a set of COPRs with the
Playground flag + the Playground DNF plugin that handles them) looks
interesting, but I would like to hear how you envision extending this
approach to support some of following features:
1) Signing packages with an independent Playground repository key. I
assume that if we add support for signing packages in Copr, each <user>
or each <user-repo> will have its own key and when the <user-repo>
becomes part of the Playground repository, we'll want to sign it with
the Playground repository key.
2) Automatic gating/sanity-check on package update. Let's say user joe
requested his foo repo be added to the Playground repository. To process
the request, packages in joe/foo are sanity-checked with Taskotron and
added to the list of Playground repositories. The next day Joe updates
packages in joe/foo and (inadvertently) breaks them so they no longer
pass the sanity-checks of Taskotron. In the case of having a real
repository, where packages are feed from COPRs (i.e. copied over), users
will continue to see the old packages in joe/foo that passed the sanity
checks, whereas in case of this "virtual" repository, they would
automatically be upgraded and break their systems.
Note about disk space constraints: Couldn't we hardlink the copied
packages so they wouldn't consume twice the amount of space?
3) Handling package/repository removals (leaving legal issues to the
other thread ). For example, user joe removes his joe/foo COPR that
was also part of the Playground repository. After a week, frank
encounters a problem with a package from the joe/foo COPR that he
previously installed on his system. His tech-savvy fried bob is trying
to reproduce the problem on his system but he is unable to since joe/foo
is no longer available.