Playground Repo Requirements Document

[Toshio Kuratomi]

On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
> Thanks for the draft. I left comments to some points, but I'd rather
> discuss it on next meeting, but because you probably won't be
> there...
> 
> My opinions on Open Questions:
> * signing - sure we need to sign (copr requirement)
>
Okay, so is this a blocker for this repository? (Necessary) or (Very nice to
have)?

> * 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?


> * I don't know what's mirrormanager. Mirroring to all Fedora mirrors?
> I guess we don't need it at start.

Basically, yes.  mirrormanager helps our mirrors coordinate where to get the
bits (only a few mirror directly from us.  the others mirror from each
other.  So they need to know that the one they're mirroring from will have
the bits they need.)  mirrormanager needs to be configured with each
repository that we want mirrored as not all mirrors will mirror all packages
(for instance, few mirrors want the obsolete fedora releases that are on the
archives server).

So let's add mirroring in general as Optional. coordinate with infra

> * self hosting - no, I guess we don't have to ship BuildRequires in
> Playground repo. It can do shipping of some packages easier.

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).

> * no reviews! It should be quick and easy. Maybe someone else than
> owner of copr repo should approve new projects, which will go into
> Playground. Maybe cla+1 could mean automatic push into Playground if
> user click on button Playground.
> 
I'd like to go the no review route but... some other policies like conflicts
and replacement of packages might need it... I think I'd defer this until
after we decide what policies we are going to have for the packages in the
repo.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/env-and-stacks/attachments/20140226/eb248958/attachment.sig>