Working on the SCL section in the PRD

[Toshio Kuratomi]

On Thu, Jan 16, 2014 at 04:51:30PM +0100, Marcela Mašláňová wrote:
> >
> >>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.
>
I do understand that some people only work on Fedora as their job rather
than their leisure activity.  What you need to understand is that you're
blaming people for not addressing your issue quickly when from my point of
view I have a very flexible schedule but the people who know about the
technical issues in SCL have been unable to meet me to discuss them and work
on issues.  I can work from 8AM my time to midnight my time Monday and
Friday.  Pick some 2 hour or more slice in there and we can work on
questions I have, working on example packages to see what pain points exist,
and so on.  Lacking that kind of direct collaboration I'm left to
1) muddle through learning all about SCLs from the ground up by myself.  2)
talk the rest of the FPC through the things I've learned only to get
a question that I don't know the answer to, and then have to wait a week
while I figure it out and then talk to the FPC again 3) after I get
consensus in the FPC, have the decision shot down because the SCL team
considers that the compromise is unacceptable and have to seek out
a different compromise.

I do this work.  The FPC does this work.  It *is* slow.  But it's because
FPC members don't think it is a good technology that it's slow.  I'm also
not saying that FPC members have pointed out problems and are hesitant about
various details of SCLS but those problems haven't prevented us from voting
to approve pieces of the guidelines once those pieces have been hammered out
into something that we can agree is the best we can do.

> >
> >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.
>
I understand that's your position.  And I've done my best to craft
a compromise with the FPC that allows that position to be reflected in the
Guidelines.  But I'm letting you know that because we're going that route
we're now subject to the timetable of the LSB to accept a revision to the
FHS in addition to our own limitations.

If you value fast, then compromise is needed.  If you value having things
exactly as you are currently doing things then you have to accept that
things will progress very slowly as we have to find ways to reconcile what
you want to do with other concerns.

> 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.
> 
Thanks, it seems like right this instant I need to talk to Jan Zeleny about
scl implementation. and try to find Slavek, Remi, or hhorak on irc whenever
I have questions about the example scl packagesets I'm working on.

> >>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 may.  My recollection is that software collections were presented to FPC as
a means to bundle software stacks in Fedora.  But that may just be how they
were presented to the committee.  Things that have changed since then are:

* Examining them deeply, we're not talking about bundling, just about more
  focus on backwards and forwards compat.
* Fedora itself is undergoing a shift in direction that includes creating
  repositories of software that are diffrent in standards and content than
  the mainstream repositories.

> 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 think you misunderstand me -- I think softwarecollections.org is a good
thing.  What I don't want to see is for "us" to have softwarecollections.org
that upstream communities contribute to and also have pretty much the same
type of repository that Fedora contributors contribute to.  I'd much rather
that softwarecollections.org was to be a Fedora project where we try to get
upstream cotributors to spend their time or a repository that focuses on
addressing the needs of both the Fedora project and upstreams (although
that's a much harder balancing act as you often feel pulled in two
directions rather than feel like your driving towards a destination.)

As I outlined before, Fedora is going to need repositories of SCLs that do
not follow the Fedora Guidelines because we're going to want to allow people
to deploy the platform that those SCLs implement as opposed to them creating
new platforms within Fedora.  Since legally softwarecollections.org seems to
have the same requirements as copr and in fact, be using copr to create the
packages hosted there, I would like to see us use the softwarecollectins.org
repository for that purpose.  But that only works if we're willing to
combine interests and address issues that Fedora will have as well.  If we
can't seek for common goals, then Fedora will have to have its own secondary
repository that works towards similar goals.

> >>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
> >
> 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 start talking with jzeleny.  The problem with talking with you is that
you often punt the question on anyway so if your goal is to try to get things to
go faster, then first talking to you and then talking to jzeleny just takes
more time.

-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/20140116/941ce967/attachment.sig>