Goals for 0.3.0

[David Zeuthen]

On Wed, 2004-07-21 at 11:38 -0400, Joe Shaw wrote:
> On Wed, 2004-07-21 at 13:57 +0200, David Zeuthen wrote:
> >     Once the spec matches the code the code and spec will stay in
> >     sync. This is important.
> 
> Yes, absolutely.  Let's never stray again.
> 

Yeah, I'll start looking at it tonight. I'll probably want to change a
few things in the code as well wrt. property names so it may break a few
things (thinking mostly the net.* and maybe the ieee1394* stuff, but
nothing major). I also want to remove the info.is_virtual stuff, that
just doesn't make sense.

> >  4. Timeframe for hitting 1.0 is Q1/Q2 next year (sorry for sounding
> >     like a PHB). I've got no idea whether this is realistic but I think
> >     and hope so.
> 
> What are the criteria for a 1.0 release?  This just seems like a random
> guess to me without more solid info.  

Yeah, it is a random guess, my gut feeling. Most of the 'difficult'
things are done, although a few do remain

I suppose the things we want are the following (apart from items on the
TODO list):

 - coverage of all mainstream bus devices supported by kernels
   (should be pretty easy)

 - coverage of all mainstream class devices supported by kernels
   (should be pretty easy)

 - HalDevices saved to disk
   (Finishing the work Kay started)

 - per-user properties?
   (I'm beginning to think we don't even want this; desktops would
    probably like to use their native configuration environment e.g.
    gconf KConfigXT)

 - some kind of testing framework so we do a 'make check' and doing that
   will relax us a bit
   (might be implemented by a 'test' backend much the same way we got
    a 'linux' backend)

 - cleanup of the code; e.g. fixing all the @todo's left in the code
   and stuff :-)

 - verification that this stuff can run other kernels - e.g. at lest
   a dummy backend that only exports the root Computer HalDevice

 - preferable support for other kernels with reasonable coverage of
   bus and class devices (FreeBSD)

 - caching in libhal; libhal using the persistent files.
   maybe some discussion on how to make libhal more useful

 - integration with key device libraries, e.g. libgphoto2 and others

 - some kind of sanity check that hal can 'power' (PHB words again,
   sorry!) some kind of desktop environment manager app - e.g. the
   gnome-device-manager I've been mumbling about at both GUADEC and
   here. 

 - reasonably successful integration into one at least OS/distribution
   e.g. verifying we can use callouts to modify legacy configuration
   files e.g. for networks works

 - DBUS API/ABI freeze

But that is only my guessing - I haven't thought a lot about it, I agree
it would be good to discuss 1.0 goals:-). Yikes, so Q1/Q2 2005 seems
awfully close now?

Did I miss anything really important?

> Is this going to be a time-based or feature-based release?
> 

That's a good question, I suppose time based releases would be a good
thing given we want stable and development series. I see no cons of this
really, only pros, but that just might be me :-)

What's your opinion?

Cheers,
David
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal