What would it take to make Software Collections work in Fedora?

[Rich Mattes]

On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal <rvokal at redhat.com> wrote:

> On 12/06/2012 07:00 AM, Adam Williamson wrote:
>
>> On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:
>>
>>> On 12/05/2012 03:06 PM, Bill Nottingham wrote:
>>>
>>>> Matthew Miller (mattdm at fedoraproject.org) said:
>>>>
>>>>> Three things:
>>>>>
>>>>> 1) Fedora is big enough that we have concrete situations where one size
>>>>>     doesn't fit all. Puppet being broken on F17 (and probably F18 as
>>>>> well)
>>>>>     is a fine example of something within the distro itself. And, as a
>>>>>     platform for development, offering more version choices to our
>>>>> users
>>>>>     would be a strength.
>>>>>
>>>>
>>>> <heretical>
>>>>
>>>> Well, then maybe Fedora's too big, and we should move to a model where
>>>> Fedora is much smaller, and the grand Fedora universe contains things
>>>> that
>>>> are packaged *for* one or multiple Fedoras.
>>>>
>>>> </heretical>
>>>>
>>>
>>> FWIW (probably not much), I also think this is a great idea.  It feels
>>> strange to me that the same thing contains & manages everything from
>>> base system (e.g. kernel through core GNOME stack) and add-on apps (say
>>> Battle for Wesnoth, to pick a relatively obvious example).
>>>
>>> Now, there's a bike shed to be painted over where the lines should be
>>> drawn.
>>>
>>
>> We could draw them between Core and Extras!
>>
>>
> So what if we actually do .. but in a different way - eg. we would ensure
> that we have stable API, no feature breakage in a release for a package
> that do belong to "core" and allow faster turnaround for packages in
> "extras" .. it's not like locking it down as it used to be but defining
> more strict rules for certain set of packages.
>
>
> Doesn't this describe the critpath[1] process?

Rich

[1] https://fedoraproject.org/wiki/Critical_path_package
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121207/b702ba16/attachment.html>