Hi,
Sven Neumann wrote:
> David Neary <bolsh@xxxxxxxx> writes:
> > IMHO, we shouldn't bump the version requirement unless there's a
> > very good reason to do so.
>
> There are very good reasons. We already prepared the tree to use the
> new file chooser and everyone is looking forward to revamp the menu
> system based on GtkAction. These are very important changes that
> should go into the GIMP CVS tree as early as possible.
I think that we could perhaps do the version bump in an organised
way this time, at least? Perhaps have a 2.1.0 with a couple of
weeks work (basically, the stuff which is waiting to be committed
more or less now, but can't go into a 2.0 branch), and announce
that it is the last release that will use gtk+ 2.2? Or even have
a few releases, and do the version bump in (say) early March? You
say "as early as possible" - I would argue that it's not
realistic to bump versions until people have had a while to brace
themselves.
> > We're anticipating a
> > certain amount of breakage after 2.2 anyway with the integration
> > of gegl and its development, so at that point it would be more
> > reasonable to start upping the required GTK+ version (perhaps
> > even to 2.6.0 when we get there).
>
> IMO it is a lot more important to get the mentioned GTK+ changes than
> to start to integrate GEGL.
I guess I should clear up what I mean by "ship with gegl" here. I
haven't talked in depth with people about this yet (neither the
gegl developers or gimp people), but I'd like to see something
like what Subversion does with Neon. They realise that Neon is
not a commonly available package, so in their tarballs they
package the last released Neon version - their build scripts
detect if it's present (or you can specify a directory where you
already have an installation), and build it for you, or use the
existing build.
It seems obvious to me that gegl will need to start making a
plan, and making milestone releases, soon if we want it to be
usable for the end of the Summer. That mean that it needs to be
used and built, and all the rest.
What I would propose is that the GIMP CVS module have an app/gegl
directory which is linked to the gegl module, so that doing a cvs
co of the GIMP would also check out gegl. We wouldn't actually be
using any of the functionality in there, just building it. And in
tarballs, we would release a snapshot of gegl along with the
GIMP. It wouldn't gain us anything in the 2.2 release, perhaps,
but I think it mlight be enormously beneficial to gegl. It would
also allow some gimp developers to get more familiar with what
gegl is, and what it can do, and so on. And why not start
migrating some app/base code to app/gegl, and making some trivial
use of gegl for 2.2, as mitch suggested some time ago?
This is not something which would cost a huge amount to the GIMP.
Like I say, I'm not talking about throwing out base and replacing
it with gegl now, but I think that it'll benefit both projects if
we start including the gegl sources in our tarballs with the 2.1
series.
> > If we start depending on software that
> > isn't commonly available yet, we risk to waste some of that
> > opportunity.
>
> I don't follow you on this argumentation. Especially not since
> GTK+-2.4 will probably be released around the time we release
> GIMP-2.0. Depending on it is a must and I don't believe it will make
> us loose a single seriously intersted developer.
It's not the seriously interested developers I'm worried about,
but the casual ones who might eventually become serious
developers, if we don't piss them off or make it hard for them to
follow the GIMP development cycle. We need more people building
from CVS than we had in 1.3.x, and we're not going to have that if
we depend on bleeding-edge build tools or libraries.
--
David Neary,
Lyon, France
E-Mail: bolsh@xxxxxxxx
