Re: Modest proposal for successful releases

["Brian C. White" <bcwhite@verisim.com>]

> >I could easily see this if debian involed a lot of "development".  However,
> >Debian is mostly about taking other people's development & testing, and
> >fitting it all together.
> 
> But if the idea is to make an official Debian, I think some development is
> absolutely necessary.

Agreed, but is 3 months needed?  The other problem, of course, is that
upstream changes are coming through in a pretty constant manner.  Thus,
you're just as likely to have a change come through the last day of
the "development" cycle as on the first day.


> Sorry, about my opinions... I'm not *really* such a shit :-) But through all
> the years I've become a cynical, opinionated cracker pot ;-)

No appology necessary!  People tell me I've become cynical since I finished
school and started working in the Real World(tm).


> Many fields, that come with Debian are great... and that I'm typing here
> proves it.  However many fields don't work... for different reasons.  One of
> this is 'setlocale()'... it has big/little endian problem with the locale
> definitions.  The program 'date' doesn't display locale format, this is
> because GNU just released it with its *own* strfrm() which bypasses the
> fully functional code in the library, and strippes off NLS.  The decimal
> character, because of the big/little endian, shows up as '\0' in some LANG
> environments... the 'sort' program is outdated and was developed back in 1987
> as a hack.  And, some locales will display '12345' or '123^@45' instead of
> the normal '123.45' (or '123,45').
> 
> And waiting for upstream changes is close to a waste of time... even if
> libc2.0 will solve some problems, it will probably introduce others equally
> bad or worse.
> 
> These are just a few fields, which I can relate to in practice... that have
> to be fully functional in an official or commercial product (IMHO).

Okay, just to be clear...  You're saying that some of Debian's time should
be spent actually repairing problems such as these and passing the fixes
upstream?

It's a novel goal, though personally I don't think it would work out too
well.  The time some maintainers have is extremely limited and they prefer
to spend time on what they like.  And, since it's all volunteer work, the
only real payment these people get is satisfaction.  If they don't enjoy
fixing other peoples mistakes, they are not likely to be effective at it.


> You won't get much compaints from a normal user as a result of some of these
> failures... a normal user would just judge the system as *not working* and
> get it from commercial parties (Which is probably why some of the functions
> above haven't reached Linux land... these functions are *hot* commercial
> ability... CDE stuff ;-)

Commercial parties, of course, can provide money as incentive to work on
things that are not as "fun".  This makes it much easier to create a fully
functional system, though generally not as "cool".
                                             
                                          Brian
                                 ( bcwhite@verisim.com )
                                             
-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com