Re: [patches] Git repository

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Fri, 8 May 2009, Heikki Orsila wrote:

> I was very pleased to hear that eglibc project exists. I have two 
> issues / suggestions:
> 
> 1. Would you accept strlcpy()/strlcat() functions into eglibc?
> 
> 	http://www.rocketaware.com/man/man3/strlcpy.3.htm

Adding new functions to the exported interface (for platforms supported by 
FSF glibc) is a bad idea; we cannot assign GLIBC_* symbol versions, there 
is no good reason for these functions to be static-only and if they were 
added with an EGLIBC_* symbol version, even in a disabled-by-default 
option group, it would inevitably lead to unwanted incompatibilities of 
binaries between GNU/Linux distributions.

> 2. Have you considered switching from SVN to Git? Git would improve 
> some operations:

I see no significant value in doing so unless the FSF glibc maintainers 
wish to pull patches from EGLIBC.  A straight conversion of the SVN 
history would mean continuing to import snapshots from FSF glibc into Git 
(with whatever third-party tools may be available for importing snapshots 
with Git; neither SVN nor Git has a proper equivalent to "cvs import" so 
"svk import" is used at present) which means there are no benefits from 
being linked to FSF glibc history; recreating the repository based on a 
clone of glibc with separate logical changes applied manually would be a 
large amount of work it would have to be up to the EGLIBC Consortium to 
direct, and it seems to me that would not be justified without interest 
from the FSF glibc maintainers in pulling a substantial proportion of the 
EGLIBC changes if that were done.  Furthermore, the SVN repository allows 
atomic commits across libc, ports and cross-localedef, all of which are 
considered indivisible parts of the whole in EGLIBC, whereas FSF glibc is 
using separate repositories for libc and ports and so committing 
cross-component changes would be complicated and non-atomic were 
repositories based on FSF Git to be used.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx