Hi Dave, Dave Neary <dneary@xxxxxxx> 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
