Re: Modulesets Reorganization
- From: Josselin Mouette <joss debian org>
- To: desktop-devel-list gnome org
- Subject: Re: Modulesets Reorganization
- Date: Wed, 02 Jun 2010 15:14:18 +0200
Le mercredi 02 juin 2010 à 13:04 +0100, Lucas Rocha a écrit :
> > http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
>
> I think you missed the point. We're not distros. We provide a platform
> and components to build distros and other products. So, yes, distros
> should probably just pick the software that best fit their target
> audience and stick with them. So, the argument in the linked message
> doesn't apply to us in the exact same way than distros.
Maybe not in the exact same way, but I fail to see why it wouldn’t
apply.
Let’s take a simple example. People write two different burning
applications, SuperBurn and MegaBurn. GNOME doesn’t want to pick one of
them in the official module set and just features them both. The
sound-juicer developers prefer SuperBurn and tightly integrate s-j with
it. OTOH the rhythmbox developers love MegaBurn and write advanced
plugins for it, while integrating SuperBurn is limited for technical
reasons.
Facing such a situation, we distributors have no good solution. We can
choose to ship one or the other solution, but it will be less
satisfactory and will require more resources than having one of them
chosen by GNOME. In this example, we were able to switch from n-c-b to
brasero in a single shot with one major GNOME release; we would never
have been able to do so if the GNOME release team hadn’t made a
decision. The brasero support in applications would never have been so
good if the switch had been made optional.
The fact that we can (and will) make decisions will not magically bring
the same amount of resources into supporting them without upstream
backing us.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “A handshake with whitnesses is the same
`- as a signed contact.” -- Jörg Schilling
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]