cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Yar Tikhiy]

On Sat, Aug 25, 2007 at 05:06:08PM -0400, Daniel Eischen wrote:
> 
> No offense, but some things have been going in without being discussed
> an -arch or -current.  Approval for committing still has to go through
> re@, but that doesn't mean that changes shouldn't be vetted elsewhere
> prior to being sent to re@ approval.

Pardon me, but how could I know that symbol versioning was a sacred
cow and my intention to use it should have been discussed on -arch?
I asked explicitly on -developers if we had a policy regarding
symbol versioning and got no definite replies but those on the
purely technical side of the issue.  Therefore I concluded that
symbol versioning is just a tool available to developers at their
discretion.  I don't have to post each my change to -arch beforehand
just because I use the highly dangerous C language, do I?

Second, no offense intended from my side, either, but have you
realized what arguments did you use against my change in this thread?
They are more or less as follows:

- Please don't commit it, or it will make me unhappy.
- Symbol versioning is there to help release engineers,
  not to work around silly bugs elsewhere.
- I'd disapprove it if I knew about it.

These are not valid arguments for a technical discussion in an open
source project unless they can be supported by references to a
well-known document.  You obviously have something to tell us in
technical terms, so please do so, we are all ears.  It would be a
great thread for -arch.

That said, I'm not going to commit the change until, and unless,
the issue has been settled.  In the meanwhile, I've started an
experiment to see if the dependence of the build system on ABI
compatibility can be addressed in src/Makefile.inc1 cleanly, without
temporary hacks.  I'll be glad to go that way if it proved possible.

But, anyway, there are at least three people in the project who
misundertood the intended role of symbol versioning.  Besides yours
truly, a humble developer, there are a core team member and a release
engineer among them.  This may be a sign that some decisions regarding
symbol versioning, which is a rather central feature for developers
and code contributors, haven't had enough exposure.  Perhaps we've
just missed some important discussions on the lists, but symbol
versioning is a long-term feature and as such it deserves a document
describing in detail how to use it in our project.

The technical side of symbol versioning puts few limitations on how
one can use it, the rest being a matter of policy.  Of course, the
choice of the policy is important and can have far-reaching
consequences, such as getting us into a complete mess or making us
technology champs like Linux and Sun. :-) Now all our symbols still
are at FBSD_1.0, and it isn't late yet to work out such a policy.
Again, it will make an excellent thread on -arch.

-- 
Yar