Re: GNOME 2.6 new modules decision: part 2



On Fri, 2004-02-06 at 18:48, Carlos Garnacho wrote:
> > 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

Not that I am talking about the Time, Users, and Networking control
panels here.

I agree. Distros have failed to get this done or even to discuss it
properly among themselves. I believe that making these control panels
part of GNOME is the only way forward, and that doing nothing will
change nothing. I think that some distros wouldn't use g-s-t at first,
but I don't think that's a problem - GNOME isn't a distro. I think the
developer community agrees with this, though it's hard to know for sure.

I think that the reasons given for rejecting g-s-t as a new module are
inadequate. There is no obstacle to solving these minor issues.  We
don't reject evolution because it's not yet completely translated, and
we don't reject epiphany because it's not yet completely accessible, and
we should not have rejected g-s-t because it is not yet perfect either.

Furthermore, when a module is rejected, we should say whether we think
it would ever be chosen and what it needs to do to achieve that. I do
not understand the decision.

> 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
> desktop:
> 
> - 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
> 
>       Carlos

-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com




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