Sven Neumann wrote:
David 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?
I'd like to note that I personally very much dislike the fact that you published these fixed dates. They haven't been discussed as such and I don't think it is helpful to set such dates at all.
I'm not pinning you down to anything - this roadmap was the result of the discussion we had yesterday on IRC, where you wanted a 2.2 release in 4 months - well, here's what that means in terms of releases with a 2 week release cycle.
I do believe that it is important to publish dates for feature and API
freezes since developers need to know about them and the earlier they
know the better.
If we're moving to a time-based release schedule (which I think we should) we also need to respect those dates.
However publishing a fixed date for each and every release that
we will possibly do during the next months is IMO the worst thing we
could have done.
OK - I could have been more vague and said "2.0 in February, branch in March, feature freeze the end of April", and left it at that. I think it's interesting to see what that means - it means that (assuming everyone is going to keep working on fixing bugs after 2.0 comes out), we have a 6 week development cycle for 2.2.0. That means 3 releases before the feature freeze, going on the current release rate. I for one think that's interesting... putting dates on it is merely a way of making something concrete rather than having vague nebulous type stuff.
Let alone the fact that release dates for 2.0.1 or even 2.0.2 are completely unreasonable since they depend on facts we cannot know yet.
I disagree... the idea should be that everyone works on stabilising 2.0 after it comes out (there's already a 2.0.1 milestone in Bugzilla which has a fair few bugs on it, and will soon have more), and then that everyone switches to the HEAD after a 2.0 branch. We can't just forget about 2.0, though, and we should try to get a stable release out before we start 2.2 pre-releases, IMHO. So we *can* plan 2.0.x releases - whatever bug-fixes are in CVS at that stage get released. It's that simple.
I would like to let people know that I will not respect any of these dates.
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.
Like I said, the release dates are not a rope to hang ourselves with - they're a guideline about when it's a reasonable time to have a release. But you're free to do whatever you like with them, including ignoring them completely.
The GIMP project is already putting up enough pressure without people trying to nail us down on release dates.
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?
The project is getting pressure from people because we don't release often, which is the whole point of the release roadmap. Perhaps it's too precise - you had the same disagreement over the last one - I for one think it's useful.
Things would be
different if someone payed a handful of GIMP developers. They could be
responsible for the milestones then and I could understand why someone
would want to see such a list. However as long as GIMP is a project
that is driven by voluntary contributions, we should IMO avoid to
publish such lists.
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.
If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun.
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.
And of course milestones aren't required, that's just ridiculous. But they can be useful. That's all... don't read more into this than was intended. Time based releases are hard, but for them to work, there need to be times. Do you think that people working on GNOME have less fun because they have a plan now?
I know GNOME users have more fun - they get all the cool stuff within 4 months of it going into CVS.
Cheers, Dave.
-- Dave Neary [EMAIL PROTECTED]
_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
