Playground Repo Requirements Document
mmaslano at redhat.com
Thu Feb 27 13:00:51 UTC 2014
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. 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?
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
> 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).
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 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
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.
More information about the env-and-stacks