> > If you are so bored that you need to organize something, come up with a
> > list of what we hope to accomplish for v7.3 and use that for a guideline
> > for when the beta will start ...
>
> That is a tough one, and something that seems very hard to organize, but
> I can try if you wish. The TODO list can easily be used for that.
> Another marking stating "Will be done for 7.3" is all it needs. When
> all the marks are turned to dashes (done) we are ready for beta.
I think that planning a date to go beta is a good thing. It forces people to
get their work done before that date, or wait for the next release. We seem
to see alot of, "I hope this patch isn't too late for version X". Defining a
date to go beta lets people know this ahead of time. Also, any planned date
is just that, a plan, not a rule. Things can /should be moved when / if need
be.
It might make sense to do something like KDE where developers inform the
release maintainer of a feature they plan to implement in the upcoming
version. This allows the creation of a site that tracks planned features,
and their status (complete, in progress, not started). Of course not
everything would need to be planned ahead of time, but the timing of the beta
would be based on the planned work.
