Hi Dave,

Dave Neary <[EMAIL PROTECTED]> 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

> 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.

Gimp-developer mailing list

Reply via email to