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

Nick Lewycky wrote:

> 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 understand your feelings, and I'm very keen on working on some interesting
stuff again, now that the ban is broken :)
But lets not forget about the bugs. We have an issue tracker precisely
to be able to track our work and to define upfront what goals we want
to reach (and reaching them we call 'hitting a milestone'). That helps
us focus on stuff and get things really done, not just started.

> 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.

I agree, but only to a certain degree. I do think that there needs to
be a barrier, i.e. things have to be discussed before they get committed.
I agree that it is important to encourage people to contribute, but I'm
totally against the idea of 'commit now, fix later'.

>> 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?

I would like to see a much more regular / frequent release cycle. May be
three months is a good interval.

For my part, I'd like to get back to a couple of design issues:

* focus management: think about how different controllers arbitrate
   focus and related global resources. Having that will make it possible
   to work on menus and other transient graphics.

* events / gestures: I'd like to finally check in a little sandbox
   to play more with Unidraw. Unidraw is a wondeful testbed for complex
   event handling, where we can test how to make the server flexible
   with respect to what gestures to expect and how to react to them
   (direct manipulation).

These tasks are pretty long and complex, so I don't expect them to
be manageable in a three month timescale. And in general, I don't
think we should focus only on those tasks we think we'll close before
the next release, or else we'd not be able to work on long-term projects
at all. But may be some progress could be visible after a while.
What about 'task: provide a simple menu system' ?

> 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.

that sound like very worthy goals. And may be some research into how
to make the GLDrawingKit more efficient, or how to provide an alternative
GLDrawingKit, based almost exclusively on display lists ?

Stefan