Working on the SCL section in the PRD

[Toshio Kuratomi]

On Wed, Jan 15, 2014 at 10:33:01AM +0100, Marcela Mašláňová wrote:
> 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
> >Fedora.
> >
> What do you mean by other platforms? Some collections?
>
Yes.

> 
> >== 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>
> >
> 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.
> 
Sounds good then.  I think it would be easiest to simply install from
softwarecollections.org then.

> >== 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?
> >
> >-Toshio
> 
> 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.
> 
Yep, that's been a missing piece.  I don't think we've ever been put in
touch with him directly.

> 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).
>
Yeah, that's incorrect.  SCLs haven't passed yet because there isn't an
overlap in time that the people who know the technical details about SCLs
are available to work with me.  This hasn't been a problem for me before
because sometimes I work 16 hour days but it seems to be a problem now.

> 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.
>
The FPC has identified problems with SCLs so there is a reson that the SCL
Guideliens haven't been approved yet..  But as for slowness, it's because of
the inability for me to work with the people who know SCLs technically in
long sessions that we've been unable to resolve those quickly.  Many people
on the FPC have reservations about SCLs but that hasn't stopped us from
voting to approve various things.

Another problem has been that there are times when the FPC has found that it
can reach a compromise solution but the SCL team has argued vehemently to
use something else that doesn't have consensus.  This then requires me to
try to build up a new compromise position with possibly other work to make
people happy.  For instance, the FPC was able to build up a consensus on
using /usr/scls as the basedir for scls.  However, the SCL team was adamant
that they wanted to use /opt instead.  So I had to craft a new compromise
around getting FHS changes so that /opt would be an acceptable location.
I submitted a patch to the FHS and have been taking time out of my schedule
to attend LSB meetings because of that.  Until the LSB accepts some version
of my patch we won't be able to approve the SCL Guidelines because we won't
be able to approve the use of /opt that the SCL team wants.

> 
> 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.

But what are each of them doing?  I need to understand who to contact with
which questions.  As you mentioned earlier, Jan Zeleny seems to be the one
to contact about changing scl-utils.  But who and for what purposes should
I contact the rest of these people?

Stakeholders I know about that need to be involved in talks are: the FPC.
Someone who represents what Fedora and EPEL packagers want to do with
packages (thus far, I think Remi has fit this role the most), and mattdm and
sgallagh who want to use SCLs to promote Fedora to developers.

> 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 Fedora project.
> 
To me that would be a shame.  We're either going to need to work closely with
softwarecollections.org to somewhat directly ship their products or we're
going to have to setup something very similar to it in Fedora and ship that
instead.  Now traditionally, Fedora has pushed to ship things in Fedora
instead of working with external repositories but I thought that one of the
goals of Fedora.next was to change that where it made sense (and this case,
since the legal issues seem to be resolved in the same way as coprs seems
like a good test case for that).

> 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.
> 
If I talk to jzeleny and he says one thing, can I take that to mean that
that's the consensus for the group?  What about the other stakeholders you
mention by name?  Is Langdon one of those people as well or is he separate?
I got some answers from mirek the other night... is he a stakeholder too?
When you say you can't speak about RHEL, what does that mean?  Or did that
mean "RHEL customers"? ( I can understand you can't speak for the
customers).

-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/20140115/c337e965/attachment.sig>