Playground Repo Requirements Document

[Tadej Janež]

On Thu, 2014-02-27 at 14:00 +0100, Marcela Mašláňová wrote: 
> On 02/26/2014 08:04 PM, Toshio Kuratomi wrote:
> >> * signing - sure we need to sign (copr requirement)
> >>
> > Okay, so is this a blocker for this repository? (Necessary) or (Very nice to
> > have)?

I think we would all agree that signed packages bring many benefits and
it would be very nice to have the packages signed. I'm not sure whether
it should be a mandatory requirement of the Playground repo or not.

> Couldn't we sign only packages, which will make it into the 
> repository?
> They don't have to be signed by copr, don't they?

I agree that this is a separate thing from COPR. We'll need a service
that will do the gating / policy enforcement and then feeding the
packages to the Playground repo anyway. The signing could be a part of
this service.
Or do you think we could live without this service and somehow implement
things into COPR + semi-automatically populate (and sign) the Playground
repo?

Also, should we estimate the development time needed by the needs we
will identify for this repo (e.g. how long it will take to develop the
signing with sigul, 'build from a git repo url and revision hash'
feature in COPR, etc.) so we can see what should go into the "minimal
viable product"?


> >> * I would prefer rolling updates and no testing repository. It's
> >> Playground, bugs can be there.
> >
> > I would prefer rolling release as well.  One clarification, by this we mean
> > there will be a Playground yum repo per Fedora release-arch.  Within each of
> > those repos, we'll have rolling updates.  Correct?

+1.

> > I would vote the opposite.  self-hosting has been a fundamental guarantee of
> > Fedora for a long time and even in the playground repo I wouldn't break
> > that.  (For those who might not know the term it means:  The Fedora release
> > repo + Fedora updates repo + playground repo should contain all the packages
> > needed to build any package in the Playground repo).
> >
> Packaging some dependencies might take a lot of time. I can't think 
> about good example now, but I remember Big Data SIG didn't want to 
> maintain Scala, but they depend on it.

I agree with Toshio here.

The argument that some dependencies might take a lot of time to package
could be mitigated by the fact that the packaging guidelines for the
Playgroud repo will be greatly simplified compared to the current FPG.
Hence, it will be easier to package up all the dependencies.
Also, since library bundling will be allowed, the packager could at
first just bundle all the dependencies in the package of interest and
later, if it would be practical, separate them out into independent
packages.

Tadej