Working on the SCL section in the PRD

Jan Zelený jzeleny at
Wed Jan 15 12:23:45 UTC 2014

-- snip --

> At the meeting, it was mentioned that the
> 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
> 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.

That's the plan for SCLv2.

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


Please don't complicate and over engineer things around scl-utils. As much as 
this fact might be unpopular around here, scl-utils is and always will be a 
RHEL-targeted technology first: the way how this works is that it solves 
particular problems for particular users/maintainers without breaking stuff for 
the others. I stress that this approach has always worked well.

If you have specific requirements for scl-utils that prevent you from building 
or running your collections, file a bug please, I encourage all users and/or 
maintainers to do that. But please don't try to put together any committees or 
anything similar that would have an artificial influence on the project, that 
would most certainly kill it.

Thanks for understanding

More information about the env-and-stacks mailing list