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

On Fri, Nov 22, 2002 at 12:16:17AM -0500, Stefan Seefeld wrote:
> 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.

How about we always work on bugs as a background activity (of course),
and make the nasty ones release critical when they show up?  I agree
that we shouldn't be spending lots of time in feature freeze at this
point; it's not like anyone is depending on our releases being stable.

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

Perhaps an intermediate position can be reached, again?  I know where
you're coming from Stefan, and I'm inclined to agree, but I worry that
if we spend all our time arguing with people who want to contribute,
telling them how their idea isn't good enough yet, we'll never get any
contributions.

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

You think so?  It's really not that much, but I have no practice at
estimating these things :-)

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

Perhaps our goal should be to get out a release every ~3 months, with
the goal that every release should have _something_ new and vaguely
nifty in it?  (Ie, not just bug fixes and tweaks to the WidgetKit
look.  Unless we reach the point where we decided to spend a whole
milestone just fixing bugs, but hopefully we'll never reach that
point :-).)

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

Well, here's something I was thinking about: what if we made it a goal
for M2 (or possibly M3) to have _something_ done on events and/or
text?  (to pick two major critical subsystems that have been stalled
for ages).  It's like the old Brooks quote: "Plan to throw one out;
you will anyway."  So we could make it a goal to have _some_ kind of
new text system implemented by M2/3, not feature complete, not
Correct, but it could be more useful than what we have now.  The
point, though, wouldn't be to make it more useful, but that it would
get people actually writing code, and learning the sorts of things you
only learn from actually working with a system... what do people think
of this?

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

Well, there's always the discussion about moving the display graph
inside the server, that'll make things more efficient :-)

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."

This email may be read aloud.