Date: Sun, 26 Aug 2007 11:35:35 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Daniel Eischen <eischen@vigrid.com> Cc: src-committers@FreeBSD.org, alfred@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, Ken Smith <kensmith@cse.Buffalo.EDU>, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <20070826073535.GD21352@comp.chem.msu.su> In-Reply-To: <Pine.GSO.4.64.0708251703550.19091@sea.ntplx.net> References: <20070824.172212.74696955.imp@bsdimp.com> <Pine.GSO.4.64.0708242252520.15344@sea.ntplx.net> <20070825053302.GG99474@comp.chem.msu.su> <20070825.093925.43008968.imp@bsdimp.com> <1188071752.1853.44.camel@neo.cse.buffalo.edu> <Pine.GSO.4.64.0708251703550.19091@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070826073535.GD21352>