Playground DNF plugin

[Tadej Janež]

On Wed, 2014-04-16 at 15:42 +0200, Miroslav Suchy wrote: 
> 
> Why you need separate key?

To enhance the security by clearly separating packages which belong to
some (random) COPRs and those which belong to COPRs that are part of the
Playground repository.
(BTW, will (future) signing in Copr use a separate key for each user or
a separate key for each user-repo?)

For example, secondary arches in Fedora use a different key than the
primary arches. RPMFusion uses different keys for free and nonfree
repos.

> I did not thought about none above. Mostly because I am thinking about
> it as Playground with very low limits (and very low responsibility and
> accountability). And when I play on playground I expect that some of my
> sand cakes are sometimes destroyed/broken. And event Playground draft
> state that
>   "Users of the repository should be willing to endure a certain amount
> of instability when using packages from here."
> 
> What you wrote here sounds too much complicated to me. Like next
> instance of fedora-updates. And if you count in the Taskotron, then it
> is even strict then current fedora-updates (in a term of process not
> packaging).
> 
> I thought that Playground will be something like the-best-of-Copr plus
> projects heading toward inclusion in Fedora.
> Just start with simple stuff and see what works, what cause most pain,
> and what is best and then evolve.
> Rather then creating complicated beast and later find that it was wrong
> direction.

There are three points I'm trying to make:
1) I agree that the Playground repository should have very low barrier
to entry with regards to packaging policy to attract new
packagers/upstream application developers. In that sense, it will be a
"playground" for them.

2) However, since the Playground repository will have very low barrier
to entry, people will make all sorts of strange things (intentionally or
not). That's why I'm advocating that we make the tooling more robust to
such packaging mistakes and include automatic package sanity checks.
Indeed, it may complicate things a bit on the implementation side, but I
think it will be worthwhile since it will cause less pain to the users.
The packagers of the Playground repository will see no additional
complication. I would even argue that helpful notifications and
explanations of their packaging mistakes will improve their packaging
skills.

3) I agree that we should "start with simple stuff and see what works,
what cause most pain, and what is best and then evolve." Therefore, I
agree that sanity checking with Taskotron, signing, etc. could all be
left out of the first (beta) version.
However, I would like to see that our current plan/architecture for the
Playground repository provides the possibility of adding all that
functionality later. Otherwise, we'll have to throw things out later and
start over.
Can you explain how you see the current plan/architecture extendable in
the future?

Tadej