Hi,

Dave Neary writes:

What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review.

I think our policy is to encourage people to use bugzilla and the mailing-lists, and not to contact developers directly. I for one do generally not accepct any private GIMP-related mails. This doesn't mean that I ignore them but in most cases I ask people to use the public channels. I believe that this policy is a good thing. If we ask people to contact developers directly, we rely on these developers being responsive at all times (which they cannot be, they might be busy or on vacation). We would encourage off-list discussions and those bear the risk that imporant ideas are lost because the right people don't hear about them. It also means that these discussions are not archived and generally not accessible by the rest of the crew.

It puts names and faces on the organisation for magazines, articles, interviews, presentations.

Is that desirable? Wouldn't it be nicer if we could show the world that GIMP is a collaborative effort?

I agree that we need to communicate better and that in particular the web-site should be improved. But I would rather like to emphasize the team aspect than to put names on the official GIMP site.

Sven

Hi,

Dave Neary writes:

I think our policy is to encourage people to use bugzilla and the mailing-lists, and not to contact developers directly.

Do you mean is, or should be?

I think it is and it should be.

I agree that that is the current policy, but disagree that things should be like that. Mailing lists and bugzilla are for the most parts an excessively high barrier to entry for people not already in the community. The quantity of mail we're talking about is not huge either - just because a name is on a website somewhere does not mean that all of a sudden they're going to get slashdotted by 10000 mails a day.

I am getting several hundred mails a day already and only the fact that GIMP related stuff goes nicely sorted into GIMP folders makes it possible for me to react to these mails in a reasonable fashion. Ideally I would not receive GIMP related emails to any private email account (but of course this happens and will continue to happen). However This is my private problem however and I don't think it's a valid argument in this discussion...

I believe we should be much more flexible about how we use those public channels, too... for example, someone recently reported a bug on a mailing list. The bug was confirmed on the mailing list, and the fix was trivial. In spite of that he was asked to create the bug on bugzilla so that it would be fixed in the next release, which probably meant taking 5 more minutes than he had already taken to create a bugzilla account. That was, imho, unnecessary.

It is a very common policy for a lot of projects that all bugs must be reported in Bugzilla. Some projects even go so far that you must not commit anything w/o refering to a bug-report. I don't think we need to go that far but I think that it is important that bugs are entered in Bugzilla. So far every bug reporter who was asked to use Bugzilla has managed to create a bugzilla account and has entered his/her bug there. If bugs are mentioned on a mailing-list or (worse) in private email it is very likely that they will be forgotten.

To comment on your example, if I would have had the time to fix the bug immidiately, I wouldn't have asked the bug reporter to file a bug report. But since I didn't have the time, I wanted to make sure the bug is entered to our bug-tracker. Otherwise it would likely have been forgotten. The bug was entered and someone else fixed it. Would this surely have happened w/o the bug being reported correctly? I doubt it.

Private e-mail is a much nicer way to get involved, particularly if you manage to talk to someone who listens to you and encourages you. I sent my first patches to Daniel Egger, because his name appeared pretty often in the changelog at the time. Daniel was very nice, pointed out where I could improve my patches, committed them for me, and at a certain point pointed me towards the lists and towards mitch when the patches got a bit bigger. In short, Daniel made it easier for me to contribute.

I am not saying that we should disallow private emails but I am arguing that we should not encourage them. Of course a lot of people are not familiar with the way that open source projects work but it should be our goal to help them to learn how to get involved.

If I send a patch to the list, it's actually sending it to no-one. Same thing with a bugzilla report. No-one is responsible, no-one says "I can't help you with this - but person X might". There is no way to know whether a patch will get applied, acknowledged or whatever. Plus, I need to sign up for a list where I might get another 100 mails a month to add on top of the 2 or 300 I already get if I'm a free software developer.

That is simply not true. If you file a bug-report against GIMP, you usually get a respone in less than a day. The problem is entered into a database for later reference and a bunch of people immidiately get to know about it and can comment on it.

I'm not saying that we should actively encourage people to send mail directly to developers, I'm saying that we shouldn't actively *discourage* avenues of communication. If someone contacts me personally with a question (which happens more and more frequently), I reply to the question as best I can. I'm reasonably pleasant, polite and friendly. If I can't help them personally, I might add someone better placed to help as a CC. Or I might reccommend that they ask the list. But if I can help, I do. Sure, there might be some gem of wisdom lost to the mail archives, but the chances are that the GIMP has made a new friend, someone who'll go away and say that the GIMP guys are really nice and approachable.

If I get a private mail and this happens more ane more frequently, I am pleasant, polite and friendly. But if I get the impression that the subject of the mail could be of concern for anyone but me and the person who mailed me, I politely ask the sender to use the public channels. And I think that everyone should do that.

If instead I say "I can answer your question, but first you have to sign up to a mailing list and ask your question there", they're more likely to go away thinking that the GIMP guys are kind of uptight, maybe they'd consider that rude, perhaps they might even go away saying that the GIMP developers are arseholes.

It's just a matter of explaining the reason for this. If you tell people that their question is certainly interesting for more people and that you would like to answer it in a public forum that gets archived, I haven't yet seen anyone who didn't subscribe to the lists and asked there. What you get is another happy user of the mailing list that might soon start to answer questions of other users or become otherwise involved.

Bear in mind that this has very little to do with the fact that you're being polite or impolite. They're asking for help, and you're insisting that they conform to an artificial structure which makes them go out of their way to get help.

Do you have an example to keep up this argument? From my experience it is void.

Most of the discussions that would happen off list would be patches sent to people "in charge" of modules, for comments and/or committal.

That's probably the worst thing that could happen. I can live with the idea of people discussing development in private emails but patches hiding in private inboxes instead of being attached to Bugzilla is what can kill an open source project.

Of course, if you're talking about design decisions, those should eventually happen on-list. But there's a certain value in 2 or 3 people getting together to flesh out ideas and come up with a coherent proposition before going to the list. In fact, often times, starting technical discussions on the list can be a disaster because you invariably end up getting stuck in the nitty-gritty of the detail.

You are of course free to do that. Is there any need to discuss this? We will certainly not tap on developers email to check if they are discussing off-list. But I don't think we should encourage people to address developers directly. The web-site should have clear and easy instructions on how to get in contact with the GIMP developers, not how to get in contact with individual module owners.

Also, we have tried every so often to keep a list of module owners. All you get is a list of names that is outdated before you finished to put it on online. Have a look at PLUGIN_MAINTAINERS. Do you really want to publish this? The responsibilities and interest of GIMP developers are changing, new people coming, other people retiring. Any attempt to track is futile.

Teams need leaders and roles. The German football team doesn't walk out on the pitch wondering who the captain is, who decides where people are playing, or who goes in goal. Even when people play sport for pleasure, there are captains, positions, goalies, subs - teams work better when people know where they fit in the team. And why shouldn't we celebrate some of the individual contributions to the GIMP?

Only because the German football team does it, we don't have to do it that way, do we? I don't follow you on this track. We have come a long way without a strict hierarchy. I enjoy seeing GIMP as unstructured as it is. The only thing that really bugs me is the bad state of our web-site.

Generally, people get more pleasure out of something where they have a sense of purpose, a sense of having a job to do. I'm not saying that we carve up the project and set things in stone, I'm suggesting that we have a number of figureheads who decide what happens for part of a project, so that the project as a whole can have some structure. As things are, we're like a bunch of headless chickens, and there are certain parts of the code that no-one touches because they're considered the property of others (for example, the text tool, pygimp, anything to do with tools, anything to do with GimpImage) - the problem is that the others don't identify themselves as the owners of the code, so nothing gets done, since there's no plan. We need a plan.

There is no plan? I think we have a very decent plan. I agree that we need to publish this plan better but I don't think we necessarily need to tie people's names to it. I would very much welcome to see a better roadmap being published than what we have currently. Again, the problem is the web-site, not some general lack of structure or lack of leadership or lack of a plan.

I can draw up a plan, but since I'm far from the best coder in the project, and I don't have any more time than I'm currently spending, the plan would be meaningless unless 3 or 4 key people agree with it. So we need structure, we need a plan, and we need someone who supports the plan to help make it a reality and organise what people do in the project according to priorities, talents, schedules and so on. If we don't do something like that, we're doomed to continue developing in all directions like headless chickens without ever getting closer to the goal (colorspaces + profiles + bitdepth + DAGs + everything else).

I wonder what makes you think about GIMP development this way. I do understand if it may appear like this to outsiders (again because of the lack of good public relations, i.e. web-site), but _you_ should be aware that there's a plan and that people are working hard to get things done according to this plan. Your comments are actually quite intimidating for everyone who's currently working on The GIMP. I take it that you are trying to be provoking for some reason but I don't understand why you are acting like this.

Sven

Hi,

Dave Neary writes:

If someone reports a bug and the bug is confirmed on the mailing list, it's a 30 second job to enter it into Bugzilla if you know bugzilla and have an account. I think that it would be nice for us to accept bug reports via that channel, and then create the bug in bugzilla when it's been confirmed (for example).

Now this turns into something we can easily aggree on. Simply because that's how it is handled already. So we will continue to encourage people to use Bugzilla and if they don't do it themselves, we put the bug into Bugzilla for them. This is good since over the last year we put a lot of work into establishing a reasonably well-working way of handling bug-reports. We cut our response-time to bug-reports down to a few hours and we cut the number of bugs down to about a third of what we had a year ago. This is definitely a success and I don't see a reason to change anything about that.

A couple of times I have had to nurse people through a bugzilla account creation and how to create a bug. Bugzilla's interface sucks (at least the version we use), so I imagine that lots of other potential contributers don't bother getting over that barrier.

Face it, if someone is not even willing to create a bugzilla account, he/she is hardly a potential contributor. So please continue to put other people's bug-reports into bugzilla (although this is a bad thing in general since it makes it impossible to get in contact with the bug reporter and ask for more details). Preferably though, nurse people through creating a bugzilla account. That is a very much appreciated effort and noone said you shouldn't do that.

If bugs are mentioned on a mailing-list or (worse) in private email it is very likely that they will be forgotten.

Not if we put them in bugzilla.

See my comment above. It is important to have the bug reporter create the bug-report herself. Of course if you can reproduce the problem, it is less of an issue but in general it is important.

While some people spend a lot of time on bugzilla, and every report gets commented on, it's hardly a formalised process for getting code into CVS. I stand by the point that when you send mail to a mailing list or attach an attachment to a bug in bugzilla, no-one is responsible for it.

I don't see why it should be that way. What's wrong about using bugzilla for patches? It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. Believe me or not, but I think getting patches into The GIMP has never been easier than today. That doesn't mean that it could not be improved but IMO bugzilla is the way to go.

The patches shouldn't rest there, but they should arrive at the person best able to handle them. If needs be, they should be attached to a bugzilla report afterwards. Again, I'm not saying that we insist that things happen this way, just saying that we shouldn't forbid people from getting into the project via a kind of mentor relationship.

I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter).

But I don't think we should encourage people to address developers directly. The web-site should have clear and easy instructions on how to get in contact with the GIMP developers, not how to get in contact with individual module owners.

Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better.

If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would.

there's no plan. We need a plan.

There is no plan? I think we have a very decent plan.

What is it? I published a set of dates, and a set of funtionalities, for 2.2 recently, and it was out of the question that we use dates (even though we ended up using "rough" dates anyway), and the list of functionality doesn't exactly constitute a plan.

Our plan is 1. Release GIMP 2.0
2. Release GIMP 2.2
3. Get gegl ready
4. ...
5. Profit!!!

OK, if the goal of all this is "Profit", then I am leaving you here. But I take it that you are kidding...

Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details.

Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits down, evaluates them and starts to hack on CMS integration for GIMP. Of course we could decide today that it needs to be lcms. But what would that yield? By the time that someone wants to start hacking on this, a better CMS might be available. Or that someone who is willing to hack on it feels more comfortable with the API of a different CMS. Do you want me to point to the plan and say "Hey, it got to be lcms because we said so half a year ago!"? No thanks, I am not going to do that.

There has been lots of discussion, but no decisions, on what gegl needs to be ready, how that will happen and when, nor has there been any decision (again, lots of discussion) on how gegl will actually be integrated into the GIMP, what implications that has for the interface, at what points we have interim milestones where we can settle things down and have a release, etc.

I don't see how we could possibly make such a decision today. I also don't see how such a decision would be helpful. This is very technical stuff. Most of the developers that would have to do such a decision haven't made themselves comfortable with GEGL yet. We have always said that we will start to go into these details when GIMP 2.0 is out. Why do you question the whole project now that we are only some days from this goal? Really, I don't get your point (or rather, I don't understand your timing).

I recently (based on a proposal of Dan Rogers) came up with a medium-term planb for integrating gegl into the GIMP, which included functionality lists, rough dates, and so on, which brought me to the end of 2005.

That's just a piece of paper without much value. You don't know if Mitch sits down next weekend and has half of your estimated hacking down before the sun rises Monday morning. There are way too many variables in such a calculation. Sure it's a plan because it has "Plan" written on top of it. However it would be a lot better if it had "Proposal" written on top of it and would be subject of discussion here. And I don't think such a discussion needs to end in a decision. Whoever writes the code decides about the implementation details. You don't need a leader or module owner for that. You need serious hackers that have fun doing some serious hacking. If you put up team leaders and module owners all over the place, people will not any longer want to hack in this environment. People do that all day long in their daytime jobs already.

What is your plan? Share it with me, because I'm not clear on what you think the plan is.

I am sticking to the plan that we made together last year. And the plan was to get 2.0 done, then start to think about what we want to have in 2.2. We also decided that we want 2.2 early, that we want to attack our goals one by one without giving up stability. As soon as 2.0 is out, I would like to prepare a list of things that could go into 2.2. Having 2.0 out should also give everyone time to look at GEGL and think about how it can fit our needs, what it is lacking and how we could start using it.

And I'll say it again - we do not have a lack of leadership. You are the leader. This is clear to everyone. What we have is a lack of a leader who says he's the leader.

If you want me to say something definite, here are my words: Calm down, help us doing 2.0 or help us doing the web-site for 2.0. If you want a plan for the time thereafter, then come back later when these goals are finished and discuss it with us. And now let's get back to some serious hacking, damned!

Sven

Hi,

Sven Neumann wrote:

Dave Neary writes:
I don't see why it should be that way. What's wrong about using bugzilla for patches?

Nothing wrong with it, but bugzilla sucks for bigger patches or features, where CVS directly is better. But then CVS sucks for co-ordinating work (by which I mean, making sure that people communicate effectively while working on some job), whereas mail works nicely for that.

It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/.

I'm not advocating going back to an upload directory...

I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter).

The encouraging needs to be done the right way. Something along the lines of "thanks for your contribution. This time, I'll create a bugzilla bug for you and attach your work so that it gets looked at. Next time, you might like to try this yourself - if you have any problems don't hesitate to mail me" is good. Something like "Patches are handled through bugzilla. You should create a bug related to your patch, and attach it there" is bad.

I'm just saying we need to be flexible, and hand-hold new contributers. There are an awful lot of communication channels in the GIMP (this was talked about last Summer) - it can be daunting for a new contributor even if all of them do a job, and are very good at that job.

Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better.

If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would.

I don't think it would be a hassle once the modules are sufficiently grained. The problem is the names to put on the modules.

I'll maintain this if I know who to send it to for the website.

Our plan is
1. Release GIMP 2.0
2. Release GIMP 2.2
3. Get gegl ready
4. ...
5. Profit!!!

OK, if the goal of all this is "Profit", then I am leaving you here. But I take it that you are kidding...

I take it you've never heard about the underpants gnomes.

Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there.

OK - the roadmap we laid out for ourselves last GIMPCon is somewhat out of date now, but it had 3 main points - 2.0 before Christmas, 6 month cycle to 2.2, integrate gegl between 2.2 and 3.0, with 3.0 in the first half of 2005.

The problem is we've overshot the first part by 3 months (no-one's to blame for this, but it's a fact), mainly because we let the feature freeze slip by over 2 months. We have had a 3 month pre-release cycle, which is what was anticipated at the time.

That means that the entire plan needs to be revised. Not only that, but the discussion we started on the gegl list about how we go about getting gegl into the GIMP, as well as what needs to be done on gegl between now and next Summer, needs to finish. It will finish when there's a decision about what we do.

We should have this discussion over the next couple of weeks, as soon as 2.0 is out.

I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details.

We're not talking about the distant future, though. In about a week we're going to start development on 2.2 without really having a clear plan about what's going into it. There were a couple of mails a few weeks ago, and there is a fairly long list of features in that list, but we don't really have a 2.2 target feature list, prioritized sop that we can cut features if they don't get started or finished in time.

And then in the meantime gegl needs to get to a state where we can use it. So we need to figure out now how we're going to use it so that the gegl guys can work towards that. That means planning now how we're going to integrate gegl in 6 months time, and what features we get from that, and what we need to add in terms of interface to use those features.

Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits down, evaluates them and starts to hack on CMS integration for GIMP. Of course we could decide today that it needs to be lcms. But what would that yield? By the time that someone wants to start hacking on this, a better CMS might be available. Or that someone who is willing to hack on it feels more comfortable with the API of a different CMS. Do you want me to point to the plan and say "Hey, it got to be lcms because we said so half a year ago!"? No thanks, I am not going to do that.

Nope, not at all. But gegl has been on the roadmap for 4 years now. gegl will have the API we want it to have. But we need to say what we need that API to be, and figure out how we'll use it. Of course, in the meantime perhaps someone will liberate a brilliant gegl-like image processing framework, and we can use that instead (that will probably not happen, though). You're not setting things in stone by saying what you're going to do.

There has been lots of discussion, but no decisions, on what gegl needs to be ready, how that will happen and when, nor has there been any decision (again, lots of discussion) on how gegl will actually be integrated into the GIMP, what implications that has for the interface, at what points we have interim milestones where we can settle things down and have a release, etc.

I don't see how we could possibly make such a decision today. I also don't see how such a decision would be helpful. This is very technical stuff. Most of the developers that would have to do such a decision haven't made themselves comfortable with GEGL yet. We have always said that we will start to go into these details when GIMP 2.0 is out.

That's reasonable. We will talk about all of those things next week or so.

Why
do you question the whole project now that we are only some days from this goal? Really, I don't get your point (or rather, I don't understand your timing).

The timing was due to other events which caused a build-up of stress - the recent discussion of 2.2 features and dates, the fact that 2.0 keeps getting delayed, the Mark Shuttleworth offer, and the ensuing discussions, which showed up some of the weaker points of the organisation, and general stress in life outside the GIMP.

The timing might be off, but I believe that most of my points have merit. I think hand-holding is the way to get more people involved in the GIMP. I think we shoudl say who is responsible for what (at least partially), and I think we should plan ahead for gegl integration now (+/- a couple of weeks) to allow the gegl developers to work towards that goal.

And I don't think such a discussion needs to end in a decision.

We disagree.

Whoever writes the code decides about the implementation details. You don't need a leader or module owner for that. You need serious hackers that have fun doing some serious hacking.

Sure, but you need hackers, and somewhere along the line, most people have a tendency to ask "does anybody mind if I try to do this?" All you're doing by having a guy in charge is having someone who can say "you should contact X, he started on that earlier and would love the help", or "No, fire ahead - that would be cool".

If you put up team leaders
and module owners all over the place, people will not any longer want to hack in this environment. People do that all day long in their daytime jobs already.

Again, we disagree. We're not talking about imposing a hierarchy, but theer has to be some structure.

Anyway - as you say, we'll talk about all this stuff in 10 days or so after 2.0.

Cheers,
Dave.

I would be willing to maintain the module maintainers list as well as any other lists relating to who to contact about this or that.

On Tue, 2004-03-09 at 14:23, David Neary wrote:

Hi,

Sven Neumann wrote:

Dave Neary writes:
I don't see why it should be that way. What's wrong about using bugzilla for patches?

Nothing wrong with it, but bugzilla sucks for bigger patches or features, where CVS directly is better. But then CVS sucks for co-ordinating work (by which I mean, making sure that people communicate effectively while working on some job), whereas mail works nicely for that.

It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/.

I'm not advocating going back to an upload directory...

I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter).

The encouraging needs to be done the right way. Something along the lines of "thanks for your contribution. This time, I'll create a bugzilla bug for you and attach your work so that it gets looked at. Next time, you might like to try this yourself - if you have any problems don't hesitate to mail me" is good. Something like "Patches are handled through bugzilla. You should create a bug related to your patch, and attach it there" is bad.

I'm just saying we need to be flexible, and hand-hold new contributers. There are an awful lot of communication channels in the GIMP (this was talked about last Summer) - it can be daunting for a new contributor even if all of them do a job, and are very good at that job.

Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better.

If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would.

I don't think it would be a hassle once the modules are sufficiently grained. The problem is the names to put on the modules.

I'll maintain this if I know who to send it to for the website.

Our plan is
1. Release GIMP 2.0
2. Release GIMP 2.2
3. Get gegl ready
4. ...
5. Profit!!!

OK, if the goal of all this is "Profit", then I am leaving you here. But I take it that you are kidding...

I take it you've never heard about the underpants gnomes.

Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there.

OK - the roadmap we laid out for ourselves last GIMPCon is somewhat out of date now, but it had 3 main points - 2.0 before Christmas, 6 month cycle to 2.2, integrate gegl between 2.2 and 3.0, with 3.0 in the first half of 2005.

The problem is we've overshot the first part by 3 months (no-one's to blame for this, but it's a fact), mainly because we let the feature freeze slip by over 2 months. We have had a 3 month pre-release cycle, which is what was anticipated at the time.

That means that the entire plan needs to be revised. Not only that, but the discussion we started on the gegl list about how we go about getting gegl into the GIMP, as well as what needs to be done on gegl between now and next Summer, needs to finish. It will finish when there's a decision about what we do.

We should have this discussion over the next couple of weeks, as soon as 2.0 is out.

I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details.

We're not talking about the distant future, though. In about a week we're going to start development on 2.2 without really having a clear plan about what's going into it. There were a couple of mails a few weeks ago, and there is a fairly long list of features in that list, but we don't really have a 2.2 target feature list, prioritized sop that we can cut features if they don't get started or finished in time.

And then in the meantime gegl needs to get to a state where we can use it. So we need to figure out now how we're going to use it so that the gegl guys can work towards that. That means planning now how we're going to integrate gegl in 6 months time, and what features we get from that, and what we need to add in terms of interface to use those features.

Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits down, evaluates them and starts to hack on CMS integration for GIMP. Of course we could decide today that it needs to be lcms. But what would that yield? By the time that someone wants to start hacking on this, a better CMS might be available. Or that someone who is willing to hack on it feels more comfortable with the API of a different CMS. Do you want me to point to the plan and say "Hey, it got to be lcms because we said so half a year ago!"? No thanks, I am not going to do that.

Nope, not at all. But gegl has been on the roadmap for 4 years now. gegl will have the API we want it to have. But we need to say what we need that API to be, and figure out how we'll use it. Of course, in the meantime perhaps someone will liberate a brilliant gegl-like image processing framework, and we can use that instead (that will probably not happen, though). You're not setting things in stone by saying what you're going to do.

There has been lots of discussion, but no decisions, on what gegl needs to be ready, how that will happen and when, nor has there been any decision (again, lots of discussion) on how gegl will actually be integrated into the GIMP, what implications that has for the interface, at what points we have interim milestones where we can settle things down and have a release, etc.

I don't see how we could possibly make such a decision today. I also don't see how such a decision would be helpful. This is very technical stuff. Most of the developers that would have to do such a decision haven't made themselves comfortable with GEGL yet. We have always said that we will start to go into these details when GIMP 2.0 is out.

That's reasonable. We will talk about all of those things next week or so.

Why
do you question the whole project now that we are only some days from this goal? Really, I don't get your point (or rather, I don't understand your timing).

The timing was due to other events which caused a build-up of stress - the recent discussion of 2.2 features and dates, the fact that 2.0 keeps getting delayed, the Mark Shuttleworth offer, and the ensuing discussions, which showed up some of the weaker points of the organisation, and general stress in life outside the GIMP.

The timing might be off, but I believe that most of my points have merit. I think hand-holding is the way to get more people involved in the GIMP. I think we shoudl say who is responsible for what (at least partially), and I think we should plan ahead for gegl integration now (+/- a couple of weeks) to allow the gegl developers to work towards that goal.

And I don't think such a discussion needs to end in a decision.

We disagree.

Whoever writes the code decides about the implementation details. You don't need a leader or module owner for that. You need serious hackers that have fun doing some serious hacking.

Sure, but you need hackers, and somewhere along the line, most people have a tendency to ask "does anybody mind if I try to do this?" All you're doing by having a guy in charge is having someone who can say "you should contact X, he started on that earlier and would love the help", or "No, fire ahead - that would be cool".

If you put up team leaders
and module owners all over the place, people will not any longer want to hack in this environment. People do that all day long in their daytime jobs already.

Again, we disagree. We're not talking about imposing a hierarchy, but theer has to be some structure.

Anyway - as you say, we'll talk about all this stuff in 10 days or so after 2.0.

Cheers,
Dave.

Hi,

Thomas Simmons wrote:

I would be willing to maintain the module maintainers list as well as any other lists relating to who to contact about this or that.

Thanks for the offer of help. After we've discussed this some more (after 2.0), it'd be great to get you on board.

By the way, you might consider snipping a little bit out of the mails you're replying to :)

Cheers, Dave.

On Tue, Mar 09, 2004 at 09:29:02AM +0100, Dave Neary wrote:

I'd like to propose that the following roles be defined and published on the site (if it ever gets updated).

Help: Roman Joost

If the gimp-help-2 team has nothing against this, it'll be okey for me to be published on the site.

Greetings,

On Mar 9, 2004, at 10:46 pm, Roman Joost wrote:

If the gimp-help-2 team has nothing against this, it'll be okey for me to be published on the site.

Certainly fine with me.

Servus, Daniel