on moving toward a 2.4 release
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
on moving toward a 2.4 release | William Skaggs | 11 Aug 18:09 |
on moving toward a 2.4 release | Robert L Krawitz | 12 Aug 01:49 |
on moving toward a 2.4 release | Alan Horkan | 12 Aug 18:39 |
on moving toward a 2.4 release | Sven Neumann | 14 Aug 09:26 |
on moving toward a 2.4 release
GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on December 19, 2004. This was a 9 month release cycle, which is quite reasonable. Howver, it has been over a year and a half since the 2.2 release, and we are still not visibly nearing a 2.4 release. This slow progress is holding up important things, including, especially, GEGL integration. What can be done?
The first step is to make a complete list of the remaining critical functionality issues -- the things that must be resolved in order to permit a string freeze. The most reasonable way of making such a list is to use Bugzilla: every critical issue should have a bug report with target milestone set to 2.4, and severity set to "Blocker". Things that will not prevent a string freeze should not be marked as blockers at this time.
I would like to suggest that we set a hard deadline (say Sept 1) for identifying critical functionality issues -- that is, if an issue does not have a "Blocker" bug report by then, it will not be considered critical, and will not prevent a string freeze. Once we have a complete list of issues, we can make a concrete plan on how to deal with them, and start moving forward more efficiiently.
In any case, something has to be done to blast us out of the current state of near-paralysis.
-- Bill
______________ ______________ ______________ ______________
Sent via the CNPRC Email system at primate.ucdavis.edu
on moving toward a 2.4 release
Date: Fri, 11 Aug 2006 09:09:44 -0700 From: "William Skaggs"
GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on December 19, 2004. This was a 9 month release cycle, which is quite reasonable. Howver, it has been over a year and a half since the 2.2 release, and we are still not visibly nearing a 2.4 release. This slow progress is holding up important things, including, especially, GEGL integration. What can be done?
Compared with us (Gutenprint), that's still positively speedy.
GIMP 2.2 is a great application, albeit with some serious limitations (no 16-bit support, etc.). I'd personally prefer to see you folks take more time -- even quite a bit more time -- to get it right rather than try to rush a release. Keep doing 2.2-based releases with incremental functionality while working on a next generation release that will really improve matters.
I was hoping that we'd be able to do our followon to Gimp-Print 4.2 within 12-18 months, but it didn't work out that way -- it was more like 4.5 years between Gimp-Print 4.2 and Gutenprint 5.0. There was a lot of churn along the way, but we rearchitected a lot of the internals to come up with a really general option system and a fully orthogonal 16-bit internal architecture (i. e. all of the input types we accept are capable of both 8 and 16 bits). Doing that design -- along with beating the color architecture into shape -- simply took a lot of time.
If GEGL integration really is a hard problem, it's going to come out a lot better if you take the time to do it right rather than rushing it. I'd like to see a 16-bit GIMP as much as anyone -- it's a critical part of a RAW-based workflow, and it's needed for HDR imaging, which is something I'd really like to try -- but it's going to be a lot better if it's done right.
on moving toward a 2.4 release
On Fri, 11 Aug 2006, Robert L Krawitz wrote:
GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on December 19, 2004. This was a 9 month release cycle, which is quite reasonable. Howver, it has been over a year and a half since the 2.2 release, and we are still not visibly nearing a 2.4 release. This slow progress is holding up important things, including, especially, GEGL integration. What can be done?
Compared with us (Gutenprint), that's still positively speedy.
Compared to Debian stable ... life cycle of Giant turtles ... etc.
The longer the cycle continues without a release the more often users get told thing are fixed in CVS or the unstable branch but if they are not sure what they are doing then they should not use the unstable branch for important work.
If GEGL integration really is a hard problem, it's going to come out a lot better if you take the time to do it right rather than rushing it.
If I remember the dicussions correctly 2.4 was planned, to be followed by the integration of the Google summer of code results and then GEGL after that. Where you suggest more 2.2 releases more 2.4 was what was previously suggested.
on moving toward a 2.4 release
Hi,
On Fri, 2006-08-11 at 09:09 -0700, William Skaggs wrote:
In any case, something has to be done to blast us out of the current state of near-paralysis.
We are in what? There are several people working hard and they all have the 2.4 release in mind, concentrating on the important things that absolutely need fixing. We are getting closer to a 2.4 release continuously. Where is this near-paralysis?
I don't think we will get a 2.4 release any quicker if we put more time into bug maintainance. There is a already shrinking number of outstanding issues for 2.4 and we should use our time to fix them.
Sven