Re: libcanberra as an external dependency

On Thu, 2008-08-07 at 23:16 +0200, Olav Vitters wrote:
> On Thu, Aug 07, 2008 at 01:24:55PM -0400, Joe Marcus Clarke wrote:
> > Bastien Nocera wrote:
> >> We're trying to kill esound completely, and having the release-team look
> >> in the other direction when we're adding those new dependencies is the
> >> easiest way for us to move in that direction.
> >>
> >> In any cases, it's the distributor's decision which sound server to use,
> >> but I wouldn't want to be the one wasting (a small amount of) time
> >> writing an esound backend for libcanberra.
> >
> > So what's the point of even having dependency lists?  This seems like
> > broken release engineering to me.  We're going to bless one sound
> > server, but no one actually use it.  Instead, introduce support for
> > another.  Maybe that way people will see the light, and switch on their
> > own.  That seems like a pretty passive-aggressive approach by the
> > release team.  If you want to move something better, do it.  You did it
> > for gvfs and gtkprint.
> What is not clear about esound being deprecated?
> another list:
> "The following modules are heading towards planned deprecation. They
> will continue to be supported and API/ABI stable throughout the GNOME
> 2.x series, but we do not recommend using them in new applications
> unless you require functionality that has not already been moved
> elsewhere. Check the ProjectRidley page for more details about upcoming
> changes to our platform. "
> How clear should a deprecation be? IMO it clearly states that although
> we won't break esd, we recommend that new apps switch to something else
> when it is available. This is like gvfs, we're moving away from it.

What's not clear is what that SOMETHING ELSE is.  When gnome-vfs was
deprecated, gvfs/gio were already part of the GNOME Desktop/Platform.
There was clear direction on where to move.  There is no other
recommended sound server option.  Since the Desktop hasn't yet switched
to something new, I think it is reasonable to assume that compatibility
should be maintained for the current sound server.


Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome FreeBSD org
FreeNode / #freebsd-gnome

Attachment: signature.asc
Description: This is a digitally signed message part

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