From: Sven Neumann sven@xxxxxxxx > 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 release cycle. 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. -- Bill
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
