Playground DNF plugin

[Radek Vokál]

----- Original Message -----
> On 04/16/2014 12:34 PM, Tadej Janež wrote:
> > 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.
> 
> Why you need separate 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 [3]). 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.
> 
> 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.
> 
> Mirek

+100 .. please don't put up more walls than necessary. The intention has been as Mirek stated, the reason why Fedora is not getting any additional developers and maintainers might be that we put the bar very high to get in. That's the reason why we've started working on COPR and that's a reason why we're discussing Playground and it should be super-simple to get packages/new features in for testing with the risk that you might break stuff. Better to do it in Playground than in Fedora-updates right? 

Radek

> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
>