Playground Repo Requirements Document

[Toshio Kuratomi]

On Thu, Feb 27, 2014 at 01:53:06PM +0100, Marcela Mašláňová wrote:
> On 02/26/2014 06:54 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
> >>there...
> >>
> >Some notes on the comments:
> >
> >The Legal comment.  I think you and I agree.  If the language is unclear,
> >could you rerite it?  I basically am wanting to duplicate the guidelines for
> >copr as theoretically, the requirements for this repo and copr repos can
> >differ (the requirement that a non-free software but distributable license
> >is not okay in copr is a fesco policy, not a RH Legal requirement.
> >Similarly, the decision that Fedora itself doesn't ship non-free software is
> >a Board decision.
> >
> What if we check licenses by licorice (scanning licenses)? It can't
> find every strange licence, but enough to pass legal requirement. My
> team tested it on bigger set of packages and output was quite good.
> We could set legal flag if bad license occurred in package and rest
> could go into repo without manual review.
> 
> https://github.com/tradej/licorice
> 
Yes, I might not have been clear -- we don't necessarily have to check that
packages comply with the policy before the packages can get into the
repository.  The License policy, for instance, could be applied if people
notice and complain, for instance (because this is what spot has okay'd
for coprs in general).

Having an automated tool would be even nicer :-)

Conflicts  and replacement policy might be something that needs checking
before it goes in (as we can't take a package off of endusers' systems so
we might want to make sure that these play nicely before pulling them in).
However, that might be something we can automate...If possible, we really
should automate as we could then run it everytime we're merging in new
builds.  Given that packagesets will vary over time, 

> >The Conflicts and replace comments.  I thought it had been decided that
> >conflicts and replacements should not be allowed.  If that wasn't
> >a decision we should probably kick those choices back down to the open
> >questions.  I've done so now and we can discuss that on the Open Questions
> >part of this thread/the next meeting.
> >
> >-Toshio
> >
> You are right we reached some conclusion on conflicts and replace,
> but what if we want for example new v8? We have terribly old v8 in
> current Fedora and conflicts might be a good solution in this case.
> 
<nod>  I'm perfectly willing for us to reopen this discussion.

There's pros and cons to each idea.  Allowing replacement might be better
than Conflicts for the case you mention, though.  With replacement, there's
the chance that the end user can continue to use Fedora software that was
built with the older version of v8 in mind.  With Conflicts, chances are
that the users would always have to choose whether to install the set of
packages that were built against the Fedora Main Repo version or the set of
packages that were built against the Fedora Playground 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/20140227/39cef683/attachment.sig>