Re: glib-1.3

[Josh MacDonald <jmacd CS Berkeley EDU>]

My discussion with Tim, and all of the mail this has generated
has really filled me in on the way things are.  I personally 
disagree with some of the policies but that's okay.  If the
glib-1.2 and glib-1.3 lines can be merged then eveyrone's problems
go away for now.  I still view this as a critical situation 
which needs a long term solution.  Fundamentally, the policies
being set by the GNOME and GTK development efforts is really 
restricting our collaborative potential.  Forcing development
of one package to depend on stable lines of other packages is
infectuous, and everyone using glib and gtk has been infected.
By making development of one project depend on stable lines of
another use of the development version is severely limited and,
according to the policy being set by Miguel (due to his understood
interest in maintaining a user base), all projects must progress
in a synchronized, lock-step fashion.  That means my development
has to move at the speed of the rest of yours, and that bothers
me greatly because I think it is a far greater threat to our 
overall productivity than whether GNOME has a lot of users up
until its next release (my attitude is: provide a superior product 
and people will have no other choice but to switch, but do not
let the current interest level or an attempt to maintain a user
base on a less than superior version derail the project--focus on 
the future not the past).

That said, the most serious issue here is not how I deal with 
Xdelta's dependency on glib-1.3.  I am completely tired of 
special-case configuration hacks in my own programs to deal with
my glib troubles.  If I can't use 1.3 then 1.3 and 1.2 must be 
merged.  I began using 1.3 when it had a feature that 1.2 did not
and because I thought people would be moving on to the development
version--I'm not trying to be difficult, I'm just trying to use 
the contributions I make.  I refuse to contribute to a library 
where I can't add functionality and have new versions released 
based solely on the merit of the release.  There should not be
external factors limiting the rate of glib development.

It may sound like I'm making demands here, but I'm trying to 
cooperate.  I recognize that I can't just go do my own thing
with glib because it will piss the rest of you off, all I can
do is negotiate with this mailing list.  We must reach an 
acceptable ground.

The root of all these problems, which affect everyone who uses glib 
and/or gtk, is that between the clueless users and multitudes of shared 
source and binary packages our build and packaging systems seem to fall
short of providing isolation and backward compatibility for the installation
of multiple versions of the same package.  This does not require rocket
science to solve, but it DOES REQUIRE EVERYONES COOPERATION and a framework
for easily accomplishing this should be implemented for all packages
in the glib/gtk/gimp/gnome/mozilla thrust which depend on each other.
This can be crufted on top of the current automake/libtool setups we
are already using.  It must facilitate easy integration so that minimal
expertise is required to make a library that will cooperate with the
scheme.  We already have a pattern that almost works, but it requires a 
lot of customization for each project.  For a package named P there is
a script which gets installed in ${PREFIX}/bin/P-config which is used
by other programs which depend on it.  A .m4 file named P.m4 is installed
in the correct location and includes the auto-generated (or partially
auto-generated) macro named AM_PATH_PACKAGE_P(VERSION...) that can be call
from another package in order to import that packages libraries.  Installation
rules must insure that previous installations with the same minor version
number (for example) are retained.  Then, I should be able to use glib-1.3
while everyone else uses glib-1.2, and at least no one would mind releasing
a development version right now.  I would still face the problem with Miguel
forcing me to use glib-1.2, but at least we would have been able to release 
1.3 for use with xdelta-1.1 while the rest of the world remains at glib-1.2.

Right?

-josh

Quoting Tim Janik (timj@gtk.org):
> On Wed, 7 Apr 1999, Josh MacDonald wrote:
> 
> > I just released Xdelta-1.1.0 and it depends on glib-1.3.0 but there
> > is no such publically available glib version.  Would it be possible
> > for someone to make a release?
> > 
> > -josh
> 
> i just discussed matters a bit on irc with josh.
> he's based xdelta on glib-1.3, because he needs GQueue
> and eventually some other newly introduced bits.
> 
> while we certainly want to avoid (up to an extend that seems
> reasonable) the problems that appeared during the last development
> line, e.g. lots of people going bleeding edge and finding themselves
> in the need to cover up recently introduced instabilities and
> frequently adopt their code to API fluctuations, new contributions
> that won't go into the stable line have to be made available and deserve
> testing of course.
> 
> on the technical side, the matter is: when are the cool development bits
> mature enough for public consumption?
> - glib needs merging with the stable branch (i'll probbaly do that later
>   this day) and could stand some proof reading/testing of the new features/API.
> - gtk+, as it currently stands, desperatedly lacks integration of
>   the new gdk-win32 stuff (plus the issues mentioned above for glib),
>   and will probably take some time until an 1.3.x release.
> 
> so while i don't see a reasonably stabelized gtk+ version being released rsn
> (similar to owen, i don't even *run* the devel versions yet), this doesn't
> neccessarily need to apply to glib, which could imho be braught up to speed
> within 2 or 3 days.
> 
> whether we *want* to release glib-1.3.0 solely during the next few days, is
> a completely different matter, and people tend to differ on that, mainly based
> on political issues and practical problems involved.
> 
> things raised during ths discussion so far:
> 
> - as experience has shown, people will get confused about gtk+/glib
>   dependancies and what combination they are supposed to run if they are not
>   released in sync. so for one thing, if we release glib-1.3.0 now, we'll have
>   to jump gtk+'s version number at some point to release e.g. glib-1.3.1 *and*
>   gtk+-1.3.1 together.
> - package maintainers will have a hard time getting dependancies right, e.g. a
>   devel version of gimp will soon require gtk+1.2.1 and glib-1.2.1 for the gui
>   and xdelta-1.1 and glib-1.3.0 for the xd plugin.
> - people using glib-1.3 and reporting bugs against glib-based programs (every
>   gtk/gnome program, might that be gmc, gnumeric, mozilla, gimp or whatever)
>   will be told to downgrade if the program's developer hasn't switched to
>   glib-1.3 yet. this point is somewhat moot though, because in any case it
>   *will* happen at some point. either now with a glib-1.3.0 release or - say
>   in two months after glib-1.3.0 and gtk+-1.3.0 have been released.
>   developers are just more likely to have upgraded to the devel lines already
>   if glib is released with gtk+ in sync.
> - applications based on glib-1.3 (or gtk+-1.3 for that matter) cannot be
>   considered stable, until a new stable branch has been created, i.e. 1.4.
>   that's simply something app developers have to be aware of, so if they want
>   stable products, develop against 1.2.
> - contributions to glib can not be taken advantage of until there's a (new)
>   development release out there, incorporating them. autoconf plus conditional
>   compilation of extra sources is one way to get around that, but it tends to
>   be a temporary solution and gets more and more hairy over time (the
>   GTK_HAVE_FEATURES* mess in old gnome and gtk program versions is one of the
>   best examples for this).
>   thus, developers all so frequently doubt the worth of the extra hassle and
>   prefer to defer releases of their own projects, require newer releases of
>   the dependant packages and with that cause their users to go bleeding edge.
> 
> 
> while lots of these problems are actually not glib/gtk or gnome specific, but
> can be observed in other software territories as well, they tend to emerge for
> these project due to the active development and permanent feature tracking.
> 
> there's no perfect solution to this, but we should do our best to lessen the
> burden on all parties. i personally would like to urge josh to not base
> xdelta-1.1 on glib-1.3 at this point (especially due to miguel's intentions
> to base *stable* bonobo on librepo) and give glib (and eventually gtk+) some
> more room to get mature.
> on the other hand, if gtk+ continues to lack integration on the gdk part like
> it currently does (and fluctuate API wise, though that shouldn't be as much an
> issue as it has been during the 1.1.x versions), and the additions to glib are
> overseingly stabelized (especially regarding the API), we should decide on
> either releasing new glib devel versions solely for a while or start back
> merging of those additions into the stable branch.
> 
> ---
> ciaoTJ
> 
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.

-- 
-josh