Re: Removing libgnomeprint* from the desktop set

[Olav Vitters <olav bkor dhs org>]

On Mon, Mar 31, 2008 at 11:48:55AM -0500, Mike Kestner wrote:
> On Mon, 2008-03-31 at 17:56 +0200, Matteo Settenvini wrote:
> 
> > I believe the point is exactly that it's deprecated and unmaintained.
> > Putting it outside of GNOME gives a strong signal to developers.
> 
> For the record, that wasn't a rhetorical question.  I was looking for
> actual cost to the team or platform, as in effort or platform
> performance.  Not theoretical signals sent to developers.  I'm also not

s/theoretical//

For one, gtksourceview 1.x for (IIRC) GNOME 2.20.x was not shipped as
part of GNOME. Simply because the release scripts didn't support having
gtksourceview 1.x as well as 2.x. It partly supported it, causing extra
work for every GNOME release during testing.
Shipping stuff that is not maintained at all is bad. If e.g. some new
GCC causes some breakage, then there won't be some maintainer to poke.
This would cause the release to be delayed.

Other things are e.g. jhbuild build time. Although IMO the whole 'it is
not maintained' is more important that the time it causes for r-t (or
elsewhere). If it should be done, then time is not important enough to
not do that (assuming sane time values).

> convinced that the signal "hold on to your hats, cause GNOME is going to
> change under you at our whim" is the optimal signal to send.  Even for a
> desktop library.

This is a misrepresentation of what is being done. Desktop does mean
that the API could change (not 'whim'). This is btw why some libraries
are in Desktop while some are in the Platform.

> > However, this doesn't mean that library can't continue living its own
> > life outside of GNOME: it can still be packaged for a distro, or shipped
> > along with a third-party application.
> 
> It just means extra work, and confusion as to whether it "should" be
> done since it's not in GNOME any more, etc... 

I don't understand above. It is not maintained atm. No bugs will be
fixed anymore.

> > If the application in question is still actively developed, porting the
> > old code to the new one shouldn't be too much a hassle; it's not as if
> > you're removing any functionality to the platform, just saying "move on
> > to the next version, it's better and more stable and people will work on
> > it".
> 
> It tells application developers who use GNOME that you _have_ to invest
> effort into your application to keep its current feature set with the
> current GNOME release.  Effort that could otherwise be invested in
> potentially more worthwhile features.  

That is implicit by using libraries from the Desktop. Meaning: don't
break on purpose, but you're on your own when it happens.

> Instead of continuing this discussion I should probably have invested
> the time in figuring out how I can maintain stability for gnome-sharp's
> users in the face of this removal.  Most people won't be worried about
> that, since it's my fault for depending on an unstable library, but it's
> effort I could be spending elsewhere to make GNOME more available to
> mono users.

This is just maintenance stuff. GVFS/GIO vs gnome-vfs is the same. You
need to spend time on infrastructure (meaning: libraries) to have a nice
desktop/program/binding/whatever.

-- 
Regards,
Olav