Hi, Sven Neumann wrote: > David Neary <dneary@xxxxxxx> 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: dneary@xxxxxxx Tél: 04 78 58 08 83 CV: http://www.redbrick.dcu.ie/~bolsh/CV/
