Re: GNOME 2.6 new modules decision: part 2

Hi Murray!

On Fri, 06 Feb 2004 13:02:42 +0100, Murray Cumming wrote
> So, following on from the first list of decisions, which was also late:
> Here's the outstanding decisions;
> Rhythmbox:
> The maintainers have withdrawn the proposal because they do not 
> expect to meet their own targets within the 2.6 schedule. The 
> release team was ready to enthusiastically approve Rhythmbox for 2.6 
> so we thank the maintainers for their own high standards. Note that 
> the release team currently thinks that the community is likely to 
> approve both Rhythmbox and Totem+gstreamer for GNOME 2.8, if they 
> are proposed."
> Evolution, Evolution-Data-Server, gal, libsoup, etc,
> As with Rythmbox, the maintainers have withdrawn the proposal because
> they do not expect to meet their own targets within the 2.6 
> schedule. We thank the maintainers for their attention to quality. 
> There seems to be massive support for evolution in GNOME, so we 
> expect to see this in GNOME 2.7/2.8.

I'd like to give some random opinions about g-s-t

> Gnome System Tools
> It's looks like No, though not all members of the release team have
> given their full input. In general there is concern that
> - Distros are not using it yet.

what distros are we talking about? it may depend on the size/fame of the
distro (or much better, on whether they have already a set of tools or not):

a) On "big" distros we may spend years asking what could be the first, the egg
or the chicken, I don't think that distros such as redhat, suse, mandrake or
fedora will drop their own tools and begin using gst if they aren't
"supported" by gnome (even in such case, I doubt it), and OTOH, it seems that
gnome won't adopt it unless they are supported by those distros

b) on "little" distros: distros like PLD and OpenNA have already expressed
their interest submitting patches for supporting these distros (so I guess
they'll use gst ;), and other distros have expressed too their interest, but
haven't provided patches still; the gst are one of the options too in the
Debian desktop project (and I've been told that KNetworkconf, which uses gst
backends, is a candidate too for the KDE side :), Debian Sarge already has
them, and LinEx (by the Junta de Extremadura) uses gst for the config task...
and I'm told that the list is increasing

IMHO there are three groups that will benefit from the inclusion of GST in the

- GNOME itself: consistency-wise, several administration tasks are highly tied
with the desktop experience that gnome might want to offer, and keeping gnome
agnostic in this fact (by letting the distros do their way) couldn't be good
- GNOME Users: keeping a same/sane UI across distros, avoiding him/her to
learn new tools/commands, etc...
- Distros without their own set of tools: the effort of porting gst to another
distro, apart from being inversely proportional inverse to your perl-fu, is
much smaller than creating a new set of tools :).

And one group that will safely ignore g-s-t:

- Distros with their set of tools: the effort was already done, switching to
gst has no benefit at all

> - It does not yet have a perfect solution for root privileges. 

I think that this is because gst requires more than what the current auth
solutions are able to offer, when an alternative provides solutions to both
local and remote authentication, I'd be glad to switch to it

> - The menu structure for user and system preference is not fully
> decided.

fully agreed here, I'd like to work on a solution to this

> Hopefully this decision reflects the community's wishes, though the
> maintainer deserves a more constructive explanation. I will reply to
> this email to give my personal opinion.

I'd be glad to read it :)

Anyways, thanks a lot


> -- 
> Murray Cumming <murrayc murrayc com>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

Carlos Garnacho <garnacho tuxerver net>
                <carlosg gnome org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]