Working on the SCL section in the PRD
mmaslano at redhat.com
Wed Jan 15 09:33:01 UTC 2014
On 14/01/14 18:44, Toshio Kuratomi wrote:
> 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
What do you mean by other platforms? Some collections?
> == 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.
No problem. Into scl.org can be imported only projects from copr and in
copr users must agree that the content is good (licenses). scl.org will
provide with every collection rpm, which will install repository, so
user has to install it manually.
> == 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.
quagmire = marsh? I hope google translate is not lying to me again :)
> 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?
scl-utils project is developed by jzeleny, he's also the lead of rpm/yum
team. I guess you or FPC should be speaking to him first.
I don't think FPC should define new technologies. SCL didn't pass yet,
because many FPC members don't think it is good technology. (If I
missinterpred their reaction on meetings, then I'm sorry). It slowed
down the process and we had to solve lot of other things instead of
focusing on upstream improvements and availability of collections. With
the future technologies I'd like to work faster in this WG.
Stakeholders for scl-utils are long time users, sometimes commiters -
Slavek, Honza Horak, me. Jan Zeleny was already mentioned. There are
also users from other projects, usually from cloud.
scl.org will be done mainly by my team. It should be public in a month,
then we can discuss it further. I guess it's more upstream project than
I don't fully understand other questions. There is one main developer
and advanced users who did provide some patches or feedback for future
development. We were always trying to find the best solution for users,
so I guess we are working as one group. Obviously I can't speak about
RHEL and customers input on public list.
More information about the env-and-stacks