From: Sven Neumann [EMAIL PROTECTED]
> Perhaps if we could first decide what the purpose of the roadmap/task
> list should be. I tried to raise that question when we started with this
> topic. But no one ever attempted to answer it. So before we start this
> again, can we have this discussion, please. That would probably help to
> get us somewhere.
A roadmap should be thought of as a component of a full development
strategy. In my view, each release cycle should have a set of target
dates, and a set of essential accomplishments. The target dates are
for soft freeze, hard freeze, and release. The accomplishments are
the things that *need* to be done to have a release. For the current
cycle, for example, I see the essential accomplishments as:
1) stabilize the new gegl code
2) merge the toolbox and image menus
3) change to a Cairo-based canvas
That doesn't mean that nothing else can be done, just that
nothing else will be allowed to shift the target dates.
The main value of a roadmap, in this context, is in planning for
future release cycles. Thus, the roadmapping that should be going
on now is for 2.8 and beyond, not for 2.6. With a good roadmap,
the UI team can work on specifications ahead of time, and developers
can have at least some code ready to commit at the start of the
There actually *was* a roadmap for 2.6 already during the 2.4
cycle, but it was never made public. The fact that a roadmap
existed can be seen in that (1) the first gegl work began immediately
after branching for 2.5, (2) code had already been written for the
merged menus, and (3) the first experiments with Cairo started
immediately after branching.
What is needed is for this sort of roadmap to be published,
instead of just existing in the heads of people who read the
ChangeLog every day and hang out all the time in #gimp.
Gimp-developer mailing list