On 8/26/05, Michael Schumacher wrote:

As promised on IRC, my suggestions for the registry. Originally sent to the maintainer of the registry.

Sounds awesome.

1. Make it possible to indicate that a plug-in requires GIMP 2.2

2.3, and 2.4 options would be nice here too, I suppose. And also, change the list of links of types to a drop down box, maybe? (Dunno.)

2. Compress the recent changes list 3. Make the recent changes available as a RSS feed

Very useful, then I can add the RSS feed to my browser. ^^

4. Add a way to indicate the availability of binaries for a specific platform

Something similar to the way tucows.com does their listings would be a good idea.
Eg:

=====
[Plugin name] ..... [Win] [Linux RPM] [Linux Deb] [Mac OS X] [Source] [Plugin catagories] [User based rating (maybe, maybe not)] [Language/format] [Requirements (optional/if specified)] [Plugin description summary]... [more info link to full description] =====

This could be unified, as well (e.g. anywhere plugins are listed this format would go there).

Hi,

michael chang writes:

1. Make it possible to indicate that a plug-in requires GIMP 2.2

2.3, and 2.4 options would be nice here too, I suppose. And also, change the list of links of types to a drop down box, maybe? (Dunno.)

2.3 is a development version with no API guarantees whatsoever. The API is constantly changing and noone should be developing any plug-ins for it. And 2.4 shouldn't be added before the 2.4 release.

Sven

On 8/26/05, Sven Neumann wrote:

Hi,

michael chang writes:

1. Make it possible to indicate that a plug-in requires GIMP 2.2

2.3, and 2.4 options would be nice here too, I suppose. And also, change the list of links of types to a drop down box, maybe? (Dunno.)

2.3 is a development version with no API guarantees whatsoever. The API is constantly changing and noone should be developing any plug-ins for it.

If you have such a closed Gimp Club attitude, why make developer releases at all? After all, all the members of the Gimp Club have cvs accounts. One of the most important reasons that we have preview releases is so that when 2.4 is released, third-party plugins are already available for it. It's abundantly obvious that 2.3 is a developer edition, with all that entails, and both users and plugin developers are aware of the fact that things can break, but that doesn't mean that it's counterproductive to track development and to test the new features. Would you prefer that serious problems in newly added plug-in apis not be discovered until after they are frozen?

Since 2.3 cvs contains a plugin that was originally maintained separately, and GIMP was developed against gtk 1.3 long before API freeze, it's obvious that you already know this, which makes me ask the question: why did you say this in the first place? Seriously, it served no other purpose than discouraging people from testing the 2.3 series. GIMP isn't exactly overwhelmed with volunteers. We should be doing everything we can to encourage more people to try out 2.3, and more people to be testing its new features. Yes, that even includes those features that have to be accessed programmatically. Anyone who is capible of developing a plugin against 2.3 is capible of fixing any breakage if we change a non-frozen API.

And 2.4 shouldn't be added before the 2.4 release.

That's a matter of taste. After all, if 2.4 is backwards compatible with 2.0 plugins, there are a ton of plugins that are already 2.4 compatible. What's not a matter of taste is that plug-ins shouldn't be marked as 2.4 compatible if they use non-frozen APIs. After the API is frozen is a different matter.

Rockwalrus

Hi,

Nathan Summers writes:

2.3 is a development version with no API guarantees whatsoever. The API is constantly changing and noone should be developing any plug-ins for it.

If you have such a closed Gimp Club attitude, why make developer releases at all? After all, all the members of the Gimp Club have cvs accounts. One of the most important reasons that we have preview releases is so that when 2.4 is released, third-party plugins are already available for it. It's abundantly obvious that 2.3 is a developer edition, with all that entails, and both users and plugin developers are aware of the fact that things can break, but that doesn't mean that it's counterproductive to track development and to test the new features. Would you prefer that serious problems in newly added plug-in apis not be discovered until after they are frozen?

The only reason I don't want to see a 2.3 version in a plug-in registry is that doesn't seem to make much sense. After all any new API could change with the next new minor 2.3 release. The version listed in the registry would also have to include the micro version number then.

I am deliberately ignoring the hostile attitude of your mail. We both know very well that we don't like each other. There's no point in continuing this in public. Feel free to flame me in private mail.

Sven

On 8/26/05, Sven Neumann wrote:

Hi,

Nathan Summers writes:

2.3 is a development version with no API guarantees whatsoever. The API is constantly changing and noone should be developing any plug-ins for it.

If you have such a closed Gimp Club attitude, why make developer releases at all? After all, all the members of the Gimp Club have cvs accounts. One of the most important reasons that we have preview releases is so that when 2.4 is released, third-party plugins are already available for it. It's abundantly obvious that 2.3 is a developer edition, with all that entails, and both users and plugin developers are aware of the fact that things can break, but that doesn't mean that it's counterproductive to track development and to test the new features. Would you prefer that serious problems in newly added plug-in apis not be discovered until after they are frozen?

The only reason I don't want to see a 2.3 version in a plug-in registry is that doesn't seem to make much sense. After all any new API could change with the next new minor 2.3 release. The version listed in the registry would also have to include the micro version number then.

All plugins will eventually go obsolete, true, regardless of what versions they compile against. Including the point release is easy enough. Chances are also pretty good that a plugin that compiles against 7.5.15 will compile against 7.5.17 even if they are both development versions. Caveat compilor, but I would be willing to give it a go, especially if it were a plugin I had a distinct need for.

I am deliberately ignoring the hostile attitude of your mail. We both know very well that we don't like each other. There's no point in continuing this in public. Feel free to flame me in private mail.

I'm sorry if you don't like me, but I like you just fine. Would you honestly want me to not speak up when you say something that's not in GIMP's best interests? If I wanted to be hostile, I would have been much, much more hostile. I would have been more subtle, but subtly is often lost on you.

So no, I will say what I think is best for the GIMP project, and I will do so publicly. If you think I disagree with everything you do, you're wrong. You have good judgement on technical matters, and I respect pretty much all the decisions you've made in that area. (The few I haven't are well-documented.) You can't possibly want me to "me too" every good decision you make like some AOLer. :)

But realize that you are not perfect, and when I do speak up, it's because I want GIMP to be the best it can be. I'm not perfect either, and I'm not always right, but I truly believe that by putting our heads together, we can all come to a mutually-agreed conclusion on what is best. GIMP used to be run by that principle, and it's my personal belief that that system can work better than any personal dictatorship ever could.

Right now one of the most serious problems that GIMP has is a lack of active developers. I will be blunt (frank, not hostile, and only because such frankness is necessary.) The reason for this is that GIMP development has become dysfunctional, and the original mail I responded to was symptomatic of this dysfunction.

Like any good dysfunction, there are several interrelated parts. One part is that a small but vocal minority of the community are quite hostilely impatient with practically any newcomer who tries to learn the ropes, and as a result, almost all of them get driven away. There were serious problems with the first patch I ever submitted to a software project. If I had gotten the treatment that most newcomers who haven't been magically endowed with the all the right skills now get here, I'd probably be working for Microsoft and spending my free time blogging about how the open source zealots don't understand the real world. Instead, I got a patient reply explaining how exactly how to submit my changes in the most suitable form, and I got very prominent mention in the release notes of the next version. Unsurprisingly, I continued to contribute to that and later to other projects.

The unwillingness to mentor potential new developers, combined with the fact that practically everyone who was willing to speak up if they didn't like a particular decision have left in disgust at your tendency to turn any disagreement into a personal matter, as you just tried to here, has resulted in a very unhealthy environment. For example, I used to spend all of my free time hacking gimp, but that is no longer the case, and the only reason for this is that it's not worth it for me to fight for every single nontrivial change or addition that I make, especially since no one is left who will back me if I don't get time to complete it.

I am far from the only contributor that feels this way. I might knock off a low-hanging feature or bug if I'm bored or it scratches a personal itch, but in general there is better bang for my hacking buck elsewhere. If that is true for me, someone who has been hacking gimp since before it had cvs, what chance is there of it not being true for newcomers? There is plenty of competition for developers in the interesting open-source project sector.

I still care passionately about GIMP, and I still feel that I've contributed enough in terms of time and lines of code that my opinions about it should mean something. I want GIMP to improve, and that rate of improvement to increase. I want more people to join the Gimp Club. If the dysfunction can't be ended then all our recruiting efforts will be almost entirely in vain, and you can bet that assuredly as lead falls when dropped near your toes that I will speak about it, and in public if I feel that doing so best suits the interests of the GIMP project.

Your friend in GIMP,

Rockwalrus

Hi,

I am not going to respond on your mail in detail, mainly for lack of time. Lots of good points being made and taken. However I would like to state that I am not at all unwilling to mentor new developers. I also think that our (and that includes mine) attitude towards new ideas and requests for changes has become a lot better over the last years. You are right that we are lacking active developers but we gained quite a few new ones recently and I am not sure if they receive GIMP development as bad as you put it. Quite a few people are rather enthusiastic about it and I would love to have more time to help them get into it.

Sven

On 8/26/05, Nathan Summers wrote:

On 8/26/05, Sven Neumann wrote:

Hi,

michael chang writes:

1. Make it possible to indicate that a plug-in requires GIMP 2.2

2.3, and 2.4 options would be nice here too, I suppose. And also, change the list of links of types to a drop down box, maybe? (Dunno.)

2.3 is a development version with no API guarantees whatsoever. The API is constantly changing and noone should be developing any plug-ins for it.

If you have such a closed Gimp Club attitude, why make developer releases at all? After all, all the members of the Gimp Club have cvs accounts. One of the most important reasons that we have preview releases is so that when 2.4 is released, third-party plugins are already available for it. It's abundantly obvious that 2.3 is a developer edition, with all that entails, and both users and plugin developers are aware of the fact that things can break, but that doesn't mean that it's counterproductive to track development and to test the new features. Would you prefer that serious problems in newly added plug-in apis not be discovered until after they are frozen?

Oh pah, stop arguing, I wasn't intending to get you guys angry. Geez. It was a suggestion. If you don't like it, that's perfectly fine -- but adding them now would prevent us having to go and bug Mr. Web Developer again when 2.4 is released. (If he has to add all plugins manually at the moment, then there isn't much point, but if it's semi-automated or automated, adding them now but placing some sort of consensus not to put things there works too.)

If it helps, why not have a (2.3/beta) or (current open beta) section, and then wipe it when 2.4 is released? Obviously, if you don't like it, that's fine...

Since 2.3 cvs contains a plugin that was originally maintained separately, and GIMP was developed against gtk 1.3 long before API freeze, it's obvious that you already know this, which makes me ask the question: why did you say this in the first place? Seriously, it served no other purpose than discouraging people from testing the 2.3 series. GIMP isn't exactly overwhelmed with volunteers. We should be doing everything we can to encourage more people to try out 2.3, and more people to be testing its new features. Yes, that even includes those features that have to be accessed programmatically. Anyone who is capible of developing a plugin against 2.3 is capible of fixing any breakage if we change a non-frozen API.

And 2.4 shouldn't be added before the 2.4 release.

That's a matter of taste. After all, if 2.4 is backwards compatible with 2.0 plugins, there are a ton of plugins that are already 2.4 compatible. What's not a matter of taste is that plug-ins shouldn't be marked as 2.4 compatible if they use non-frozen APIs. After the API is frozen is a different matter.

I presume that this statement is made assuming 2.4 doesn't become 3.0...

On 8/27/05, Sven Neumann wrote:

Hi,

I am not going to respond on your mail in detail, mainly for lack of time. Lots of good points being made and taken. However I would like

Time is always an important issue, and a lack of it may cause curtness. It'd be nice if everyone always took this into consideration, but sometimes we forget from time to time. Reminders are sometimes necessary, and this one was well placed.

to state that I am not at all unwilling to mentor new developers. I

That is very reassuring, yes.

also think that our (and that includes mine) attitude towards new ideas and requests for changes has become a lot better over the last years. You are right that we are lacking active developers but we

Indeed.

gained quite a few new ones recently and I am not sure if they receive GIMP development as bad as you put it. Quite a few people are rather enthusiastic about it and I would love to have more time to help them get into it.

Hopefully, so would everyone else... ^_^