Re: [Fresco-devel] What needs to be done for M2?

Tobias Hunger wrote:
> Now that we have that nifty tracker, how will we use it for the upcomming M2 
> cycle? Now that M1 is released (was it announced yet? Well, it is out and 
> available at the new website on www.fresco.org) we should think about what we 
> want to archive with M2 and how to go on about the release cycle.
> 
> I propose to add a couple of tasks to M2 and declare a feature freeze 
> imediently after these are done. Then we can release after and bugs of high 
> enough priority are solved.

I'd rather we learn to do our releases Hot. That is, we release off the 
HEAD when we realize that enough work has been done.

I'd also like to see us encouraging more development at the expense of 
keeping all bugs out. Review is a wonderful thing, but the barrier of 
entry for a new developer is still very high. It'd be nice to allow new 
material to be checked in first and cleaned up later. Note that this 
really depends on including the diffs in the fresco-commit mails.

> For my part I'd like to see tasks
> 8 Write coding styleguide (that's nearly(?) done anyway)
> 9 Adopt coding standard for all files
> 30 Implement a unit test framework for Fresco
> 39 Integrate Babylon's tests (currently called examples) into test framework
>       (needs to be done as part of task30 anyway)
> 40 Add a scenegraph debugging framework

Yikes. I think that expecting all of this will push M2 off the 
timescale. Are we thinking of releasing M2 "soon"? That seems to be the 
consensus, so to be more specific, do we plan to release M2 before, say, 
  Feb. 2003?

> Not much user visible stuff in that list... but it will help to form a much 
> more stable basis for M3 which then should have a couple of user visible 
> stuff in it IMHO.
> 
> What are your plans for M2? It would be nice if we could add messages to the 
> milestones and discuss things in the tracker... but then the ML has more 
> active listeners, maybe someone outside the usual crowd wants to comment:-)

My plans are to get libGL threading issues resolved, and move unifont 
support into the freetype support, now that unifont ships as .bdf which 
newer Freetype versions can read.

Nick