On 02/26/2014 08:04 PM, Toshio Kuratomi wrote:
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
> 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
Again, I don't how signing work. Mirek was discussing signing some time
ago. 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 would prefer rolling updates and no testing repository.
> 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?
Um, we probably need repo per Fedora release.
> * 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
So let's add mirroring in general as Optional. coordinate with infra
> * self hosting - no, I guess we don't have to ship
> 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).
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.
> * no reviews! It should be quick and easy. Maybe someone else
> 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
Policies should be easy to check manually, so we don't have a another
huge pile of unfinished reviews.
I concur we need to define policies first.