Playground Repo Requirements Document

[Alek Paunov]

On 03.03.2014 13:16, Honza Horak wrote:
>
> Right, that makes sense for me; allowing conflicts and updates seems
> like allow creating too big mess.
>
> I can also see another cases:
>
> 3) introducing a new package under a different name --say we want to
> prepare a new un-stable/dirty version of a package foo, which is already
> in Fedora and we'd like to introduce it in Playground (which would mean
> the package foo would be updated for every user who has enabled
> Playground). If we introduce the new package under featurex-foo or
> userx-foo, we can safely add it into Playground.
>
> 4) We have a stack of packages that I want to deliver to Fedora users,
> but the stack would update some packages from Fedora base repo and/or we
> do not want to use SCLs. Then we can get a Copr repository as a RPM
> package and include this RPM in the Playground, so people installing
> this RPM package would actually say: "Yes, I want to enable these
> packages and I agree to get some of my Fedora-base packages updated".
>

I think all 3 paragraphs above are very wise. Few more humble opinions:

3) could be extended with different (not only newer). If the packager is 
able to get the older version coherently regarding Fedora+Playground - 
why not.

4) will be really nice, but I think that for the playground .repo RPMs 
should exist some form of review (e.g. from Fedora packager or by 
env-and-stacks WG?)

I think that Playground could also play a nice role as a training camp 
for some potential Fedora packagers and if so, which elements from the 
standard process would be good to be presented in lightest possible 
variant? Random thoughts:

- github.com/fedora-playground organizational account managed by 
env-and-stacks and used as dist-git

- ~/index/wiki analog of the guidelines, containing also some important 
excerpts of the real guidelines as friendly recommendations for possible 
improvements

- ~/index/issues analog of the review request BZ, but with very easy 
ticket creation e.g. filled by web interface at playground.fp.o 
requiring just source COPR with successful builds for the requested 
arch/branch matrix. Then our machinery should check the package for the 
basic requirements: licenses, no f updates, build requires in f+p, 
coherency against f+p.

- ~/package/issues as package bugtracker synced by the github api when 
abrt or an user fills a bug against the package into the central Bugzilla.

Kind regards,
Alek

P.S. Weather someone already works on JS interface (local web app) for 
generating/supporting .specs files based on local yumdb and the .spec 
grammar?. Is this a good idea? Showing rpmbuild and copr-cli command 
lines to the future packager?