Noriyuki Soda <soda@sra.co.jp> writes:
> > It's not clear to me that if a group wants to work on and integrated
> > better locale support, it should be put off for a "to be done
> > eventually" project.
> 
> Hm. How can I put the project put off for a "to be done project" ? :-)

I don't actually think that's an illegitimate question.

If you've got a decent track record for getting projects done (I see
no reason to believe otherwise for you), and you propose what you
think is a likely time scale, and it's not unreasonable and not
sufficiently far out that it'll cause lack-of-feature problems, then i
think it's quite reasonable for others to say "OK, let's wait a bit
and see what progress he's making and whether he seems to be meeting
his schedule (and maybe help him out about on this project)."

Open-ended schedules cause nothing but problems.  note I didn't say
"to be done," I said "to be done eventually," where "eventually" is
not well defined.  8-)


> > However, it's really fairly imporant for the ABIs to be binary
> > compatible, either for better locale support that might be integrated,
> > or for whatever you're working on.  If it can't be done by API
> > compatibility, then it needs to be done via __RENAME hacks, etc.
> 
> Unfortunately, if it is completed, "struct __sFILE" (i.e. FILE of <stdio.h>)
> will be changed, thus, I suppose that __RENAME hack doesn't work well.

Wow.  yeah, any significant mods to FILE would go far to remove any
hope of backward compatibility.  *sigh*


> Yes, I know. Perhaps it is best that  we'll introduce it at the same
> time when a.out -> elf switching on i386.

Couple of issues: that's going to happen relatively soon, from what I
understand.  Also, that really doesn't help the problem.  Changing
binary formats _and_ having to bump all the major numbers at the same
time is kinda annoying.

More likely it's best to do in a "2.0" revision.


One good thing about bumping the version: it means that all of the
existing __RENAME hacks can go away.  8-)



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.