[Mono-list] I'm Confused... when is a class really 'Completed'?

[Burton M. Strauss III]

Respectfully, that's not the way it's presented on the web pages.

"Pick from the list of assemblies in the menu on the left to view the
current status of that assembly.

The tree shows items that are either missing or that have TODO attributes
associated with them. You can use the checkboxes to show only missing or
only TODO items."

Nothing about developers only.  It reads like 'This is what doesn't work -
everything else is great'.  You need to add something like:

"The class status is a broad status, aimed at developers (If something's
missing and you want to help, we would love the assistance).  Be aware that
the mono class libraries are still in the early life-cycle stages and there
are still a lot of 'TODO' and 'FIXME' issues with the class libraries."

-----Burton


-----Original Message-----
From: Miguel de Icaza [mailto:miguel@ximian.com]
Sent: Wednesday, May 07, 2003 3:16 PM
To: Burton M. Strauss III
Cc: Jaime Anguiano Olarra; mono-list@ximian.com
Subject: RE: [Mono-list] I'm Confused... when is a class really
'Completed'?


Hello,

> mono has enough 'stuff' that it's possible to write real-world, usable
> programs.  As long as you stay inside the working stuff.  What isn't
> real-world is telling me to research the source for every class I want to
> use a priori (a huge task), which is only slightly worse than finding out
> half way into coding that I can't do something the way I expected to be
able
> to.
>
> An important part of being able to use mono is the home page's "List of
> not-implemented classes".
>
> However that is generated, yeah, it's probably really, really important to
> tag the broken / unimplemented code so the list is right...

The class status should be used by developers that want to help: its a
quick way of getting a grasp on what is missing.

For other more detailed things, we track those problems in Bugzilla
(like thread abort/suspend it is a very well known issue, with many
ramifications in the GC and the runtime, and in this particular case,
the fix is being worked on, but has several layers of dependencies).

That is just an explanation of the situation.

If you want something robust you can depend on, you will have to wait for
Mono 1.0

The most we can say is `it works for what we use it for, and when bugs
are filed, we get to them within our schedule'.

Miguel