Re: Proposed Modules, My Take

[Kjartan Maraas <kmaraas broadpark no>]

søn, 16,.01.2005 kl. 11.57 +1100, skrev Jeff Waugh:
> Hey,
> 
> Gotta crank up the proposed module discussion, so here's my take on the
> proposed modules as discussed so far. It's my perspective of what the
> consensus may be, so may be tinged with a bit of personal bias. Don't be
> afraid to use the Calipers of Re-Education on me in reply to this mail. :)
> 
>  * gnome-schedule

Has had two releases.

I18N/L10N: looks like it need some loving when it comes to ngettext()
usage and string quality in general.

UI: I get the impression it tries to expose every possible feature in at
(1) and thus could be a bit complicated for some users to grasp? Haven't
looked at other desktops in detail to compare what they have in this
area. A few rough edges but nothing that couldn't be cleaned up in
little time.

Docs:

No integration with scrollkeeper/yelp it seems, has a short doc
in .html. Pressing help in  the UI didn't work.

Building: had to install gnome-python2-gconf before it would run.
Otherwise ok. Lives in GNOME CVS.

I'd be ok with it going in but it's not a big deal if it doesn't...

>  * gnome_war_pad
> 
- Has had several releases
- Has api-docs, no mention of user docs on the web site.
- Lives in an external CVS repo
- Looks like it's very complex compared to many of the current games in
the desktop, but that shouldn't be held against it I guess

Didn't have time to look at the build/localisation side of things, maybe
later...

Does it really need to be in the desktop? It seems the userbase isn't
exactly the normal gamer with the game being email based? I'm not sure
really.

>  * polypaudio
> 
> There wasn't an obvious consensus to add polypaudio (or even remove esd), so
> we're stuck with the status quo for yet another release. Hopefully if the
> planned HAL integration work is done for 2.12, we may have some chance of
> convincing the policy-scared. ;-)
> 

I agree with Havoc's point. It's been a compile time option for a long
time already, drop it and let distros decide whether they want to ship
it or not.

Who wants the annoying ding sounds anyway :-) Unless we can come up with
better sounds we're better off not having sound events at all IMO.

>  * libgnomesu
> 
> Only one module in the Desktop release is adding support for it, and it is
> not clear that libgnomesu solves the privilege escalation problem suitably
> for GNOME, for cross-platform, policy and technical reasons.
> 
If we drop it this time I'd like to see a high level of commitment from
one or more of the distro makers to make sure we get a solution in place
for 2.12. If you guys have the stomach to veto this you better come up
with an alternative ASAP :-)

>  * gwget
> 
> Very little consensus that this is appropriate for inclusion in the Desktop
> release.
> 
Agreed.

>  * gnome-doc-utils - include!
> 
> This has had a lot of positive buy-in from developers, and is used by yelp.
> Definitely should go in.
> 
Do we have a choice at this point? ;-)

>  * pygtk
> 
> The consensus seemed to be that we clearly document that pygtk-based apps
> are appropriate for the Desktop release rather than adding pygtk itself to
> either Platform or Desktop. As yet, no pygtk-based apps have been proposed
> for inclusion anyway.
> 
gnome-schedule is a pygtk app. 

>  * totem - include!
> 
> Let's do it. The GStreamer support has been dramatically improved. If we can
> watch or listen to vorbis/theora streams reliably, it's ready. :-)
> 
Agreed.

>  * galago, libnotify, notification-daemon
> 
> None of these have been used by other Desktop modules, nor have had regular
> releases during the development period.
> 
Probably better to hold off on these until 2.12 then.

>  * nautilus-sendto
> 
> Has not had regular releases during the development period, but after the
> discussion about gnome-user-share, it looks like something we should very
> seriously consider for a later GNOME release.
> 
How does this relate to gnome-user-share exactly? Maybe I'm slow here,
but I don't see it...

>  * goobox
> 
> There was a rough consensus that we should include sound-juicer instead, as
> it has been around for much longer, and is already shipped by many of our
> distributors. Choosing something entirely different seems like unnecessary
> software churn.
> 
On the other hand, we did get the impression that sound-juicer would see
more active development than it has seen this cycle. The audio-profile
stuff has close to zero testing and I don't think we've seen one release
of the new features... Worries me.

>  * gnome-backgrounds - include!
> 
> Not hugely controversial or demanding module, very little discussion, but it
> has at least had a release on ftp.gnome.org. Tentative yes, pending other
> input.
> 
Agree, not very controversial and backgrounds would be nice to have in
the release.

>  * gnome-menus - include!
> 
> Critical infrastructural component, regularly released, has had lots of
> attention. Can't ship without it. :-)
> 
No question about it.

>  * gnome-user-share
> 
> There seemed to be a rough consensus that we should be looking at a send and
> receive style interface to solve the use cases g-u-s was designed to help
> with. That, in addition to the somewhat controversial Apache and "~/Public"
> issues seems to indicate that there wasn't a strong consensus to include it.
> :-)
> 
Too many issues left to sort out IMO.

>  * gnome-keyring-manager
> 
> Very little discussion about it this time around, and it hasn't had regular
> releases during the development period.
> 
Not exactly something everyone has to have either I guess.

Cheers
Kjartan