Working on the SCL section in the PRD
mmaslano at redhat.com
Thu Jan 16 15:51:30 UTC 2014
On 01/16/2014 08:32 AM, Toshio Kuratomi wrote:
> 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
>> 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.
> 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?
>> 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.
I'm sorry, but I nor Slavek didn't receive any question from FPC or you
last few months. I told you all of us would prefer discussion happening
on mailing list (packaging), but the discussion there stopped months
ago. None of us wanted to spend every week at six o'clock online for
possible question. I understand with your working schedule it's hard to
imagine that people switch off computer at five and attend evening
classes or simply relax, but we do. I and Slavek attended first few
meetings, but it's not possible to do it every week.
>> 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.
Yes, I did. In my opinion is wrong to change something, which is widely
accepted by community around SCL. I don't want to explain to our users
why they have to change it everytime for Fedora/RHEL/whatever.
Maybe it might be working to use /usr/scls collections for Fedora
product like Cloud on Ruby collection. Imho it's still confusing, but it
might be discussed with mattdm.
>> 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.
Ok, specialist in the area:
Jan Zeleny - developer of scl-utils
Slavek - python collections
Remi - php collections
Honza Horak - daemons, databases in collections
I agree with mattdm and sgallagh who have use-cases for Fedora.
>> 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).
Well, we need to have space for SCL somewhere and it didn't happened in
Fedora past 6 months or more if you remember my first attempt more than
year ago. I was looking for different solution and
softwarecollections.org is what happened.
I'm not sure if collections in Fedora will be so big hit, that another
location will be needed. If guidelines for SCL in Fedora will be
different, there is big possibility that people stays with original
concept outside of Fedora.
>> 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
Group around SCL discuss new features with jzeleny. I guess you can take
his opinion as consensus. Langdon is more working with community around,
I can't speak for him. Mirek (I guess Suchy) knows everything about
packaging, so even about SCL, but I would prefer if you can ask general
questions to me.
I can't tell you ask those people if their primary assignment is
different and I can't tell them what to do during their voluntary work
I won't discuss anything RHEL or other products related.
More information about the env-and-stacks