Hi,

David Neary writes:

This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like.

So what?

So, without further ado, here's the updated roadmap... are there any comments?

I'd like to note that I personally very much dislike the fact that you published these fixed dates. They haven't been discussed as such and I don't think it is helpful to set such dates at all.

I do believe that it is important to publish dates for feature and API freezes since developers need to know about them and the earlier they know the better. But it is IMO a very bad thing to publish release dates. It would have been OK to say that we target a 2.0 release this month and that 2.2 is supposed to be out in summer, perhaps even in June. However publishing a fixed date for each and every release that we will possibly do during the next months is IMO the worst thing we could have done. Let alone the fact that release dates for 2.0.1 or even 2.0.2 are completely unreasonable since they depend on facts we cannot know yet.

I would like to let people know that I will not respect any of these dates. The GIMP project is already putting up enough pressure without people trying to nail us down on release dates. Things would be different if someone payed a handful of GIMP developers. They could be responsible for the milestones then and I could understand why someone would want to see such a list. However as long as GIMP is a project that is driven by voluntary contributions, we should IMO avoid to publish such lists.

If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun.

Sven

Hi,

Sven Neumann wrote:

David Neary writes:

This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like.

So what?

So what??? You're serious?

I'd like to note that I personally very much dislike the fact that you published these fixed dates. They haven't been discussed as such and I don't think it is helpful to set such dates at all.

I'm not pinning you down to anything - this roadmap was the result of the discussion we had yesterday on IRC, where you wanted a 2.2 release in 4 months - well, here's what that means in terms of releases with a 2 week release cycle.

I do believe that it is important to publish dates for feature and API freezes since developers need to know about them and the earlier they know the better.

If we're moving to a time-based release schedule (which I think we should) we also need to respect those dates.

However publishing a fixed date for each and every release that we will possibly do during the next months is IMO the worst thing we could have done.

OK - I could have been more vague and said "2.0 in February, branch in March, feature freeze the end of April", and left it at that. I think it's interesting to see what that means - it means that (assuming everyone is going to keep working on fixing bugs after 2.0 comes out), we have a 6 week development cycle for 2.2.0. That means 3 releases before the feature freeze, going on the current release rate. I for one think that's interesting... putting dates on it is merely a way of making something concrete rather than having vague nebulous type stuff.

Let alone the fact that release dates for 2.0.1 or even 2.0.2 are completely unreasonable since they depend on facts we cannot know yet.

I disagree... the idea should be that everyone works on stabilising 2.0 after it comes out (there's already a 2.0.1 milestone in Bugzilla which has a fair few bugs on it, and will soon have more), and then that everyone switches to the HEAD after a 2.0 branch. We can't just forget about 2.0, though, and we should try to get a stable release out before we start 2.2 pre-releases, IMHO. So we *can* plan 2.0.x releases - whatever bug-fixes are in CVS at that stage get released. It's that simple.

I would like to let people know that I will not respect any of these dates.

That's your choice... and since you do the builds for the releases, you have the power to impose your will on the project. I hope that you will at least respect the important points of this - that is, that we try to do a release every few weeks, and that we are careful about what we put in the HEAD once we branch off a 2.0 branch.

Like I said, the release dates are not a rope to hang ourselves with - they're a guideline about when it's a reasonable time to have a release. But you're free to do whatever you like with them, including ignoring them completely.

The GIMP project is already putting up enough pressure without people trying to nail us down on release dates.

No-one's given us a huge amount of slack over the first pre-release being 3 months after we said in August, or the feature freeze being 2 months later than we said it would be, or that 2.0 is going to be over 2 months late related to what we thought during the Summer... why do you suddenly think we're going to get a lot of crap now?

The project is getting pressure from people because we don't release often, which is the whole point of the release roadmap. Perhaps it's too precise - you had the same disagreement over the last one - I for one think it's useful.

Things would be
different if someone payed a handful of GIMP developers. They could be responsible for the milestones then and I could understand why someone would want to see such a list. However as long as GIMP is a project that is driven by voluntary contributions, we should IMO avoid to publish such lists.

I think that the fact that we're a voluntary project is a good reason to have a list. In fact, I think that having some kind of a list is independant of the type of project.

If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun.

How much fun is it when you're spending 3 years between releases? If we say it'll be done in 4 months, and leave it at that, we'll still be talking about stuff that absolutely needs doing a year from now, and we won't have a release for a few more months after that... what's wrong with saying what we want to do before we do it?

Releasing is fun, seeing people use the software you put time into is fun, 3 year release cycles are not.

And of course milestones aren't required, that's just ridiculous. But they can be useful. That's all... don't read more into this than was intended. Time based releases are hard, but for them to work, there need to be times. Do you think that people working on GNOME have less fun because they have a plan now?

I know GNOME users have more fun - they get all the cool stuff within 4 months of it going into CVS.

Cheers,
Dave.

Hi Dave,

Dave Neary writes:

This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like.

So what?

So what??? You're serious?

Yes, absolutely serious. Nothing is bad about a release that is delayed because the software isn't ready for general consumption. The reasons for this may be unforeseeable. It could be private trouble a developer is having, high workload at the job, bugs that are discovered late. Of course it would have been nice to release in time but if it doesn't happen, so what?

That's your choice... and since you do the builds for the releases, you have the power to impose your will on the project. I hope that you will at least respect the important points of this - that is, that we try to do a release every few weeks, and that we are careful about what we put in the HEAD once we branch off a 2.0 branch.

We have always done that; it's not really worth mentioning it.

No-one's given us a huge amount of slack over the first pre-release being 3 months after we said in August, or the feature freeze being 2 months later than we said it would be, or that 2.0 is going to be over 2 months late related to what we thought during the Summer... why do you suddenly think we're going to get a lot of crap now?

Because so far noone was stupid enough to say things like 2.0.0 on February, 25th. Being vague certainly is better than setting such arbitrary dates.

I think that the fact that we're a voluntary project is a good reason to have a list. In fact, I think that having some kind of a list is independant of the type of project.

I am not questioning some kind of list. But I don't want to let your list stand uncommented. It contains arbitrary dates that have never been discussed. How can it be useful to setup such a list if we haven't even agreed on things like what exactly do we want to do in GIMP 2.2? You should be aware this these dates will be cited on various occasions without being put into the right context.

How much fun is it when you're spending 3 years between releases? If we say it'll be done in 4 months, and leave it at that, we'll still be talking about stuff that absolutely needs doing a year from now, and we won't have a release for a few more months after that... what's wrong with saying what we want to do before we do it?

Releasing is fun, seeing people use the software you put time into is fun, 3 year release cycles are not.

It's unreasonable and unfair to argue like this since everyone agreed on a shorter release cycle already. This is not the point in question here.

And of course milestones aren't required, that's just ridiculous. But they can be useful. That's all...

As I said, setting a date for a freeze is required; setting dates for releases will IMHO do nothing but harm.

I know GNOME users have more fun - they get all the cool stuff within 4 months of it going into CVS.

You are not observing the GNOME development very closely then. Do to the fixed release dates, a lot of good stuff is left out of the official releases and delayed for another 6 months even though it was almost ready. However, it doesn't make too much sense to compare with GNOME since GNOME releases are a collection of packages. They need these rules in order to coordinate all the different software projects that are contained in such a release. I don't think you can draw the conclusion that such release policies would do good for The GIMP.

Sven

Hi,

On Thu, 2004-02-05 at 13:27, Sven Neumann wrote:

David Neary writes:

[snip]

So, without further ado, here's the updated roadmap... are there any comments?

[snip]

The GIMP project is already putting up enough pressure without people trying to nail us down on release dates. Things would be different if someone payed a handful of GIMP developers. They could be responsible for the milestones then and I could understand why someone would want to see such a list. However as long as GIMP is a project that is driven by voluntary contributions, we should IMO avoid to publish such lists.

If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun.

I couldn't have said it any better myself, Sven. The GIMP is a spare time project for all of us - personally I have enough deadlines and stressful release dates as part of my study. I don't need more of these during my free time.

The GIMP is being developed by a group of volunteers - Personally I'm in it partly because it's lots of fun and partly because I learn a lot during the the process. Imposing a fixed release schedule will take a great deal of fun out of the project, I'm afraid.

Don't get me wrong. I believe having a road map is a good thing. As with any major software project we too need to plan ahead. But I am convinced we should stick to only hinting at release dates like we did at the last GIMPCon. The main goal of the road map, IMO, should be documenting which major changes goes into which release - and even then this road map should not be set in stone.

It's no secret that the GIMP project is rather short on active developers these days (I haven't been very active myself lately either) - and I think setting a tight release plan/road map will only discourage new developers to start spending what little spare time they may have contributing to The GIMP.

Sincerely, ./Brix

Hi,

Henrik Brix Andersen wrote:

On Thu, 2004-02-05 at 13:27, Sven Neumann wrote:

[...] nail us down [...]

[snip]

Imposing a fixed release schedule [...]

[snip]

[...] this road map should not be set in stone.

I think both you and Sven have somewhat missed the point. The funny thing is, we are *almost* in agreement.

I'm not trying to nail anyone down. I don't think anyone is. I'm not *imposing* anything. The roadmap (as has been shown by the last one) is *not* set in stone.

However, it is precise. I don't think this should be a stick we use to beat ourselves with. I don't think we should get upset if a release isn't done *exactly* on the 31st of March or whatever. But I think that we're more likely to be close to the bigger dates if we have smaller, closer dates to aim for. I also think that we should release regularly, regardless of whether we think things are "ready" or "finished", because it's healthy for the project.

Releasing should not be a big deal. It could be as simple as doing cvs tag GIMP_2_1_1
cvs diff -r GIMP_2_1_0 -r GIMP_2_1_1 > the_diff In which case, there'd be no reason not to do it often. Currently, we impose a standard somewhat stricter on ourselves, which means that making a release takes a long time (it can take 7 or 8 hours on a fast machine). But who cares if that thing you wanted to fix didn't get done? It'll be done for the next release. A release is *not* a deadline, it's a liberation of the work of the last 2 weeks.

It's no secret that the GIMP project is rather short on active developers these days (I haven't been very active myself lately either) - and I think setting a tight release plan/road map will only discourage new developers to start spending what little spare time they may have contributing to The GIMP.

Well, myself and Sven are in agreement on the tight release plan, more or less. I think it might be a little too tight, and I personally would have aimed for a first pre-release for guadec, with a final 2.2 in August, but I think a 4 month release is possible. The *only* difference between my idea and yours and Sven's is that I think that giving concrete dates as rough guidelines for milestones is better than having bigger milestones every 6 weeks to 2 months.

I respect that you don't want to have to stick to dates. Like I said, there will be no Stazi knocking on your door if you don't. The roadmap is meant to be specific, but flexible, in my mind. If the majority opinion is against that, I will re-do a vaguer roadmap with no precise dates.

Cheers, Dave.

Hi,

Dave Neary writes:

I'm not trying to nail anyone down. I don't think anyone is. I'm not *imposing* anything. The roadmap (as has been shown by the last one) is *not* set in stone.

We all know that but your roadmap gave a different impression. Instead of pointing out what we want to achieve you gave a list of dates. Since we will not match a single one of these dates, it doesn't make sense to publish such a list.

Releasing should not be a big deal. It could be as simple as doing cvs tag GIMP_2_1_1
cvs diff -r GIMP_2_1_0 -r GIMP_2_1_1 > the_diff In which case, there'd be no reason not to do it often. Currently, we impose a standard somewhat stricter on ourselves, which means that making a release takes a long time (it can take 7 or 8 hours on a fast machine). But who cares if that thing you wanted to fix didn't get done? It'll be done for the next release. A release is *not* a deadline, it's a liberation of the work of the last 2 weeks.

Doing the release tarball takes about half an hour. What takes time is to test it, to upload the tarball, put it on the FTP site, add a bugzilla version, change www.gimp.org to point to the new release, announce the release on freshmeat, gnomedesktop.org, linuxartist.org ... You can hardly cut down much of this.

But I don't see what you are trying to argument about here. We agreed that we will do regular releases, we are already doing releases every two or three weeks. The point is just that I don't want to have a list that tells me that a release is pending next sunday. I know very well when it is about time for a release. When the time has come, I can figure out if the source is in a reasonable state for a release. Then I can try to find time to do it. If someone else would be doing the release it would be the very same thing. Now what good does it do if we tell people some release date that we are not likely to ever meet?

Well, myself and Sven are in agreement on the tight release plan, more or less. I think it might be a little too tight, and I personally would have aimed for a first pre-release for guadec, with a final 2.2 in August, but I think a 4 month release is possible. The *only* difference between my idea and yours and Sven's is that I think that giving concrete dates as rough guidelines for milestones is better than having bigger milestones every 6 weeks to 2 months.

All I can say is that a concrete release date discourages me to the point where I decide that I will rather be doing something else. As Brix said, there are enough deadlines in our lives. If GIMP starts to add more, then for me it's about time to quit with GIMP development. I just couldn't stand it.

I respect that you don't want to have to stick to dates. Like I said, there will be no Stazi knocking on your door if you don't. The roadmap is meant to be specific, but flexible, in my mind. If the majority opinion is against that, I will re-do a vaguer roadmap with no precise dates.

Some real content in the roadmap instead of meaning-less dates would be helpful. At perhaps make it a proposal for a roadmap next time.

Sven

Hi,

David Neary writes:

You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags.

Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do that. After all I am interested in people trying the release when I've gone through the trouble of doing one.

I got the point; so I'll repeat mine, and then we can stop. We're more or less agreed that to have 2.2 by the end of June, we need to
1) have 2.0 this month
2) Branch a stable development branch next month 3) Feature freeze at the start of April 4) start pre-releases in the middle of April 5) Release 2.2 the end of June.

That looks like a reasonable time frame. I expect that we will have to extend it a bit but that was the point of starting with a tight schedule. What's missing now is some agreement on what we want to achieve in 2.2 but I think we can as well delay this discussion until 2.0 is finally done.

I don't think there's any argument there. All I did was throw in a release every couple of weeks between those 5 points. I think it's helpful to show how little time there will be in this development cycle.

Some real content in the roadmap instead of meaning-less dates would be helpful. At perhaps make it a proposal for a roadmap next time.

This comment got me angry. I've calmed down now.

I am sorry, it wasn't every well worded. But your posting got me angry as well and perhaps I didn't take enough time to calm down.

Everything I post to this list that isn't meant to be a fact is an opinion, and a request for comments. If I say "March 17th is St. Patrick's Day", that's a fact. If I say "I think we should have 2.2.0 at the end of June, and I think this is more or less how to get there", that's opinion. See the difference? I asked for comments. I even got a couple of positive ones, in e-mails off-list.

Comments off-list don't count. If people want to comment on this subject, they should do it on the list. Everything else is just noise.

How much more proposally would you like it to be?

Well, your mail said "here's the roadmap" and that's what will be cited later. If the word proposal would have been used, perhaps even in the Subject, things would have certainly been easier.

Sven

Sven Neumann wrote:

Hi,

David Neary writes:

You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags.

Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do that. After all I am interested in people trying the release when I've gone through the trouble of doing one.

Perhaps people hesitate about this because they don't want to step in on what might be perceived as your territory?

If I understand correctly, you'd like to be able to have it announced on the mailing lists (as I do now), and then the people on the list make the announcement known in the places that are important to them. That seems reasonable, and I think that now that you have said so, this might well happen for the next release.

That looks like a reasonable time frame. I expect that we will have to extend it a bit but that was the point of starting with a tight schedule. What's missing now is some agreement on what we want to achieve in 2.2 but I think we can as well delay this discussion until 2.0 is finally done.

That's one reason I didn't put any meat on the bones when I made this proposal. 2.0 is the priority right now. You're contradicting yourself a bit too - one of your complaints was that there was no meat on the propsal.

Anyway - I think we can agree to maintain a vaguer roadmap. I'd still like to think that we can be sensible about trying to keep to the things we say in it.

Cheers, Dave

Hi,

Dave Neary writes:

Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do that. After all I am interested in people trying the release when I've gone through the trouble of doing one.

Perhaps people hesitate about this because they don't want to step in on what might be perceived as your territory?

I never claimed that this was my territory. Until yesterday I haven't even told anyone that I do most of the website announcements. I have always waited if someone else feel enthusiastic enough about the release to do it. Usually after a while I decide that I will probably have to do it myself. I don't like the idea of delegating such a job. It's a volunteers project, people should do what they would like to do without the need of someone telling them.

Sven

Sven Neumann wrote:

Comments off-list don't count. If people want to comment on this subject, they should do it on the list. Everything else is just noise.

Maybe they should, but that doesn't mean that they will. It's a lot easier to drop an email to the person that you agree with, than to jump into a heated discussion. And maybe a simple agreement doesn't need to be read by the whole list.

For the record, I think that there's a middle ground. I understand that people don't want an explicit timetable, and that the Gimp development shouldn't be driven by deadlines. On the other hand, if there was indeed a general agreement about the timing of the next release, the original email very effectively pointed out the implications of that choice.

(And I don't think that this added much to the discussion.)

Hello,
On Fri, Feb 06, 2004 at 01:14:24PM +0100, Sven Neumann wrote:

Hi,

Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do that. After all I am interested in people trying the release when I've gone through the trouble of doing one.

I never claimed that this was my territory. Until yesterday I haven't even told anyone that I do most of the website announcements. I have always waited if someone else feel enthusiastic enough about the release to do it. Usually after a while I decide that I will probably have to do it myself. I don't like the idea of delegating such a job. It's a volunteers project, people should do what they would like to do without the need of someone telling them.

i am curious, what sort of action would someone need to take to appear to "volunteer" for this announcement thing? would it be someone saying "would you like me to do that?" or perhaps something else ....

carol

Hi,

Carol Spears writes:

i am curious, what sort of action would someone need to take to appear to "volunteer" for this announcement thing? would it be someone saying "would you like me to do that?" or perhaps something else ....

Just doing it would do.

Sven

On Fri, 6 Feb 2004, Sven Neumann wrote:

Date: 06 Feb 2004 11:50:54 +0100
From: Sven Neumann
To: David Neary
Cc: "gimp-developer@lists.xcf.berkeley.edu"
Subject: Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)

Hi,

David Neary writes:

You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags.

Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do

If you _asked_ people might post the news but unless you asked for others to do it then I would assume that you wanted to do it yourself and have it done your way. And I'm on the list digest so I usually read the announcement on GnomeDesktop.org before I read it on the list.

- Alan