Hi,

Sven Neumann wrote:
> David Neary <[EMAIL PROTECTED]> writes:
> > Here is a roadmap with some meat on it (solid dates for
> > milestones and other stuff) - it's pretty aggressive,
> > particularly with respect to a 2.2 release next year. 
> 
> I really like the idea of setting a date for a feature freeze early.
> This allows people to prepare the code they want to get in and it
> makes it easy to reject stuff that comes to late. However I don't like
> the idea of setting release dates. While I think that your schedule is
> reasonable it should probably not be communicated outside this list
> and IMO the worst thing we could do would be to publish it on any
> web-site. This is a volunteers project. We don't know if we will be
> able to get 2.0 out in this timeline. There are too many unforseeable
> things that might happen. And who would benefit from any promised
> release-dates? IMO we can only hurt ourselves by doing such promises.
> 
> Don't get me wrong. I think your schedule is reasonable and we should
> definitely publish a roadmap but IMO it shouldn't include any dates.

Perhaps I should explain my reasoning behind putting firm dates
behind things. Fair enough, setting release dates on a volunteer
project is a recipe for disappointments when they are eventually
missed, but if you look at the troubles we have had, they are
echoed in other projects around the free software world - mozilla
and GNOME being the two that come to mind immediately. When you
say that the stable release will come whenever, then it really is
whenever.

I feel that dates create a sense of urgency... 2.0 in December
gets people thinking in the back of their minds that there's 4
months left to release. Put solid dates on there, and suddenly if
a bug isn't classified by September 8th, it's not going to be
fixed by 2.0, there are events associated with the near future. 

I think that the dual goals of getting a release as soon as
possible and getting as many people as possible working towards
that release are served by setting dates. I'm not saying that
these dates are set in stone - indeed, I expect them to slip
because certain things are going to crop up - bugs that are
blockers to 2.0, real life getting in the way of the blockers for
the pre-release, and so on.

The basic idea I have is to (1) have rough dates when people can
expect certain things to happen, and (2) maintain the roadmap so
that those rough dates are never unrealistic. So when I say
"release 26th of August", well if the release is on the 28th, I
won't be disappointed, but I know that the bug week can't happen
without the release. The idea of the roadmap is just to lay out
the events that cannot happen in parallel. Fixing dates shows
perhaps the most reasonable scenario. If we want a release before
Christmas, then, we should be aware that there are only really 2
weeks of slack that we can play with.

I'm not saying that release dates solve lots of problems. They
address a couple of problems. And they don't, in my opinion,
create any, as long as the roadmap is updated to reflect reality.

Having said all that, if the general concensus is that we should
not publish a roadmap with firm dates on it, I will modify what I
have to be a bit fuzzier. But please note that a release schedule
is not a stick I will use to beat people with. It is a tool to
help us get to where we want to be. And to let people outside our
little community know when we can expect to get there :)

Cheers,
Dave.
 
-- 
David Neary,
E-Mail: [EMAIL PROTECTED]
TÚl: 04 78 58 08 83
CV: http://www.redbrick.dcu.ie/~bolsh/CV/
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to