Hi all,

Here is a roadmap with some meat on it (solid dates for milestones and other stuff) - it's pretty aggressive, particularly with respect to a 2.2 release next year.

I think experience has shown us that we will probably have a 2 to 3 month pre-release cycle where we only concentrate on bug fixing so for a 2.2.0 release to be sane for next Summer we need to think about going into pre-release mode in March or April, which means avoiding feature seapage around January and February, which means knowing what's going into 2.2.0 more or less straight after the 2.0 release :)

Some things need fleshing out - for instance, I'm not completely clear on the outstanding features to be implemented in the text tool before 2.0, or about the exact libgimp api changes that have been foreseen. Likewise, the recent thread on gimp-help-2 only served to confuse what little grasp I had on what was required before a release with respect to the help structure. It would be nice for people who know a little bit more about these things to address them specifically.

Also, it would be nice to have this marked up for the website, and I'm not sure I will have the time to do that in the near future. A volunteer to do that very small task would be appreciated :) Preferably using the stylesheets from mmaybe or developer.g.o.

You probably see that I had anticipated doing a release tomorrow (as anticipated at camp) as a prelude to a bug week... I just had a look, and make distcheck just failed on me in the po files, so I'm going to need to look more closely at that, and might not have a release until Wednesday or Thursday. I will keep track of the actual dates stuff gets done by as well :)

Anyway, comments are welcome. Is any of this unreasonable?

Cheers, Dave.

Roadmap for GIMP development:

Aug 6-10 2003: CCC

Aug 10th: 1.3.18 release

Aug 26th: 1.3.19 release

Sept 1st to Sept 8th: Bug week

Sept 27th: 2.0 pre1

Blockers for 2.0 prereleases: -----------------------------

Path tool features missing:

1) moving of strokes/paths, 2) being able to connect two strokes, 3) dragging on curve segments,
4) libart stroking,
5) im/export into files.

Text tool features missing:

Help browser features missing:

libgimp API changes missing:

Oct 18: 2.0 pre2

Nov 1: 2.0 pre3 (Halloween release)

Nov 22: 2.0 pre4 (possibly 2.0 final)

Around Dec 10th: 2.0.0

Jan 15th 2004: Final feature list for inclusion in 2.2.0

March 2004: Feature freeze

June/July 2004: 2.2.0 (just before GIMPCon)

August 2004: The Great Pain - the GeGL migration.

Hi,

Sven Neumann wrote:

David Neary writes:

Here is a roadmap with some meat on it (solid dates for milestones and other stuff) - it's pretty aggressive, particularly with respect to a 2.2 release next year.

I really like the idea of setting a date for a feature freeze early. This allows people to prepare the code they want to get in and it makes it easy to reject stuff that comes to late. However I don't like the idea of setting release dates. While I think that your schedule is reasonable it should probably not be communicated outside this list and IMO the worst thing we could do would be to publish it on any web-site. This is a volunteers project. We don't know if we will be able to get 2.0 out in this timeline. There are too many unforseeable things that might happen. And who would benefit from any promised release-dates? IMO we can only hurt ourselves by doing such promises.

Don't get me wrong. I think your schedule is reasonable and we should definitely publish a roadmap but IMO it shouldn't include any dates.

Perhaps I should explain my reasoning behind putting firm dates behind things. Fair enough, setting release dates on a volunteer project is a recipe for disappointments when they are eventually missed, but if you look at the troubles we have had, they are echoed in other projects around the free software world - mozilla and GNOME being the two that come to mind immediately. When you say that the stable release will come whenever, then it really is whenever.

I feel that dates create a sense of urgency... 2.0 in December gets people thinking in the back of their minds that there's 4 months left to release. Put solid dates on there, and suddenly if a bug isn't classified by September 8th, it's not going to be fixed by 2.0, there are events associated with the near future.

I think that the dual goals of getting a release as soon as possible and getting as many people as possible working towards that release are served by setting dates. I'm not saying that these dates are set in stone - indeed, I expect them to slip because certain things are going to crop up - bugs that are blockers to 2.0, real life getting in the way of the blockers for the pre-release, and so on.

The basic idea I have is to (1) have rough dates when people can expect certain things to happen, and (2) maintain the roadmap so that those rough dates are never unrealistic. So when I say "release 26th of August", well if the release is on the 28th, I won't be disappointed, but I know that the bug week can't happen without the release. The idea of the roadmap is just to lay out the events that cannot happen in parallel. Fixing dates shows perhaps the most reasonable scenario. If we want a release before Christmas, then, we should be aware that there are only really 2 weeks of slack that we can play with.

I'm not saying that release dates solve lots of problems. They address a couple of problems. And they don't, in my opinion, create any, as long as the roadmap is updated to reflect reality.

Having said all that, if the general concensus is that we should not publish a roadmap with firm dates on it, I will modify what I have to be a bit fuzzier. But please note that a release schedule is not a stick I will use to beat people with. It is a tool to help us get to where we want to be. And to let people outside our little community know when we can expect to get there :)

Cheers, Dave.

Branko Collin wrote:

The trouble with the road to 1.4/2.0 was (if I, as a non-programmer, see this correctly) that the whole of the GIMP had to be changed. It was not possible to release 2.0 piecemeal, the change of 1.2 to 2.0 as the stable version had to be in one go.

Personally, I think we coould have developped some of the features in the current HEAD outside the main repository, and released something less featuresome earlier. But the code reorganisation and GObjectification (the major change in this release) was always going to take a long time. Particularly since so few people were working on it.

If I understand this correctly, this won't be the case with the change to GEGL, and even if it will be, there will be plenty of time to adapt to an upcoming GEGL.

There will be pain with the changeover to gegl. I think that if we limit ourselves just to switching to gegl, we can get a release with gegl pretty quickly after 2.2, though.

Release dates are cool, and targets too, but in the end, if there's a spiffy new feature, I want it in my GIMP.

Are you advocating a major release per feature? Or a thawing of the stable release to allow features as well as bug fixes to go in there? Or am I missing the point completely?

Cheers, Dave.