On Wed, Jul 25, 2001 at 11:18:58PM -0500, Kelly Martin <kmartin@xxxxxxxxxxxx> wrote:
> sufficiently large y. We bumped y as it became necessary. The HEAD
> revision was only occasionally required, and usually only for a short
> time until GTK+ released a new unstable version.
so what? nobody requires the head revision all the time. please calm down!
if you think about then you'd see that "requiring the head revision" as
you interpret it makes no sense.
> I don't know what "every project" you've worked on.
Probably because I didn't mention any. Why should I? Am I required to work
on a project before I can tell which libraries they use?
> This is a completely INSANE model for any project of any size that wants
> to actually get anything done.
It works fine, thank you. Do you have any _reasons_ to object, apart from not
personally liking that model?
> (Of course, project leadership in most open-source projects is almost
> completely nonexistent
You really escape me here. Project leadership is quite strong in most
open-source projects IMHO. Gimp is the exception, and worked exceptionally
well so far. To the contrary, many projects with strong leadership (glibc,
gnome, even gcc althoguh I am not that sure about strong leadership ;) had
a lot of problems. Look at all the BSD projects.
> reason why GIMP development has to be that way. It wasn't in 1.0, at
> least. I wasn't as involved in 1.2.)
I don't think the pre-1.0 "development model" (if you could call it a
model) is a goal to go for, actually.
> > if the head revision isn't compilable nobody can wotk with it.
>
> Which is precisely why GIMP developers should not rely on it. GIMP
> developers are developing GIMP, not GTK+.
GTK+ is gimp's toolkit, and breaking ties even more than already is the
case is a bad thing for both projects.
> If an individual developer WANTS to work with the head revision,
> that's fine, but development should not REQUIRE it,
why?
> should be wary of introducing dependencies on features not yet
> stabilized.
why do you think they aren't? why do you not trust mitch?
> You should require the OLDEST version that suffices, not
> the newest.
but that might well be the current head revision. your logic is this: we
could write gimp using motif and it is stable. let's not move to gtk.
progress can only be made by using newer gtk and esp. glib versions. what
yo you expect from developers: develop a second glib because glib itself
is not released yet, or just plain WAIT until it comes out so they cna
finally make progress?
> usage of GTK+.) Application authors should NEVER assume that their
> users like to live on the cutting edge.
Are you remotely aware of the fact that we are talking about development
versions here? Obviously not. EVERY free software project progresses by
using other people's work. Otherwise linux would still require gcc-2.5.2,
gimp would sitll require motif and Xfree would still have no 3d.
> Most users do not.
Most users use unstable alpha versions of gimp? Hello?
> upgrade the Linux systems that I'm paid to maintain when something
> breaks, and we should not force users to upgrade a nonbroken library
> unless the upgrade provides essential (or at least strongly desirable)
> functionality.
Hello? Development version?
> >totally unreasonable to expect non-compilability on a regular
> >base. How often couldn't you compile gimp-1.1.2x?
>
> I broke 0.99.x and 1.1.x on several occasions.
Too bad. Nobody would veer had found out if there weren't some savy users
out there who, indeed, like to be on the cutting edge and used unstable
development versions of gimp.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
