Nathan C Summers <[EMAIL PROTECTED]> writes:
> > BTW: It would have been a single command for me to revert the changes
> When Gimp first moved to CVS, and access to the source tree went from a
> strong central maintainer to many people with CVS access, the reason I was
> told that it would work is that if something is committed that the
> community agrees is not what it wants, the whole of the patch can be
> reverted with a single command.
true, but it wasn't my intention to revert all of it and since Daniel
checked in a lot of independent changes in one commit, a single CVS
command didn't do the trick.
> I don't think that Daniel's reaction was inappropriate at all. Yet
> because I'm late for class, I'll let what was said stand for itself.
> What I do think is important is that all major changes (yes, even major
> changes by Sven and Mitch) should be discussed before commiting (and even
> better, before a significant amount of effort is invested). Preferably,
> it should be discussed on both the mailing list and IRC, with any relevant
> points made on IRC echoed to the newsgroup (we all get mail and can read
> it at our convience, but only Yosh reads the stuff in #gimp 24/7)
I agree that we don't communicate changes good enough. We have tried
to outline plans for the future of The GIMP here, but the reaction on
this mailing list has been minimal. Nevertheless are all tasks
currently being worked on supposed to be listed in the file TODO.xml
which is used to generate
> I don't know how many times the first time I've heard about some massive
> change to the code for the first time in the Changelog, which is usually
> something very discriptive like:
> * some/file.[ch]: reorganized crap beyond all recognition
> (I am exaggerating somewhat. Alas, only somewhat.)
A short look at the sizes of the ChangeLog files (pre-1.0, pre-1.2,
current) makes me think that ChangeLog entries tend to be quite
descriptive nowadays compared to earlier times. But, yes, the
communication about GIMP development could and should be much better.
> Personally, I can't think of many things that can be done to discourage
> developers than this. I can't count the number of times something I have
> been working on has been broken by some massive unanounced change.
uhmm, that could have been avoided if you'd have announced your plans...
> I certainly don't want to disparge those that work actively on Gimp,
> especially Sven and Mitch. The contributations that all have made are
> very valuable. But I have to wonder if Sven and Mitch don't consider Gimp
> to have become thier own personal toy, and this overly harshly toned
> critism of Daniel's code is a good example of this. Continuing this
> pattern will do nothing to further Gimp in any real way, but will serve
> quite well to drive away the few developers that Gimp has left.
I've been upset and chose the wrong tone in my mail; probably I
shouldn't have sent a mail to this list at all. I did it because I
wanted this change to be discussed in public. I apologize if I sounded
Actually the main goal of the current work is to make the GIMP source
a nice place to hack. A better defined architecture should help to
keep changes more local. This will allow people to implement new
features without forcing them to work their way through the code for
half a year before they can dare to touch anything.
We are getting closer to our goal of moving the last files from the
toplevel application directory to their new places. When this is done,
work should start to document the subsystems that have been defined.
We will need help to acomplish this goal and it is definitely not our
intention to keep people from helping.
Of course we are also open to discuss the roadmap for GIMP
development. A slightly outdated but still valid document discussing
this topic can be found at
> And to think that only a handful of months ago I wondered why the
> excitment and number of gimp developers had died down so much...
I had the impression this situation lately started to improve.
Hopefully I haven't destroyed this trend by starting this thread.
Gimp-developer mailing list