On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal <rvokal(a)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(a)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