Working on the SCL section in the PRD

[Toshio Kuratomi]

At today's meeting there was some concern that the SCL section might not
reflect what we wanted to do with SCLs.  I proposed a partial strategy for
how we could work on SCLs but the people we felt were the most important to
get agreement on the strategy weren't present at that point.  So sending to
the list for feedback:

== Background ==

There will be SCLs in the main Fedora Repository.  Those will be produced by
Fedora packagers following the Fedora Guidelines.  These SCLs will also be
buildable for EPEL since they will exist just like any other set of Fedora
packages.  That will make those SCLs available in both the Fedora and the
RHEL ecosystems.

However, since SCLs are really defining a platform that sits on top of an
OS, we'll likely also want to give users of Fedora access to SCLs that are
not produced by Fedora and do not follow the Fedora Guidelines.  At the
moment, the most prominent of those are the SCLs for RHEL.  In the future
there might be a flourishing softwarecollections.org collection of scls as
well.  We want to give people access to install these other platforms on
Fedora.

== Strategy ==

The proposed strategy is for the SCLs produced by Fedora in the main Fedora
Repositories to basically stay with the FPC.  The SCLs in this other
category are what this working group should work on enabling.

<possible implementation note>
At the meeting, it was mentioned that the softwarecollections.org
repositories might operate under legal requirements similar to the Fedora
copr repositories would also be RH's responsiblity.  If this is the case, we
may be able to code software that asks user's to confirm they want to use
softwarecollections.org repositories and then enables those repositories for
them.  If this is the case, then our implementation may simply be writing
the software that prompts the user to enable the repositories.

mmaslano, do you have any information on this legal aspect?  We would
probably need to have something in public that we could point FESCo/Fedora
Legal at if we want to do things this way.
</implementation>

== sclutils ==

What our involvement in sclutils v2 should be was also brought up in the
meeting.  There were some general sentiments that were agreed upon but no
concrete plans stemming from that:

* scls are implemented via rpm macros which in the past has been 100%
  controlled by the distributions.  This leads us to the point that Fedora
  as a distribution needs to be involved with defining these macros.
* Not sure precisely which group should be doing this -- perhaps it should
  be FPC since this is what they've dealt with in the past or perhaps it
  should be us since we're dealing with new packaging technoilogies.
  * The point was brought up that whoever it is, they need to be committed
    to working on this issue.  If they're not, then it will be a quagmire.
    So it could even be a new group of people if that's what it takes
  * However, the purpose of this needs to be to get all of the stakeholders
    talking to one another.  Right now we have a great many stakeholders but
    their needs aren't being adequately communicated to each other.  Another
    group that coordinates would be good.  Another group that simply becomes
    another stakeholder would be bad.

mmaslano: Something I've been lacking in FPC... Could you send a list of the
stakeholders you know about and what they're doing?  Who are the active
people on upstream softwarecollections.org?   Who are the people doing
work on sclutils itself?  Who are the people working on the scls for RHEL?
How much do those groups have separate interests and how much are they
a single team?

-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/20140114/f661ee9c/attachment.sig>