Re: cygwin patches for gnulib relocation code [Was: Re: Bug in libiconv?]

[Eric Blake <eblake at redhat dot com>]

On 01/27/2011 11:35 AM, Charles Wilson wrote:
> On 1/27/2011 12:08 PM, Corinna Vinschen wrote:
>> Cygwin Versions prior to 1.7.7 are not support anyway.
> 
> This is merely semantics. You're saying that *the cygwin project* does
> not support older cygwins.  However, that doesn't mean *other projects*
> have the same policy -- see, for instance, upstream git.
> 
>> The changes
>> should work with versions at least back to 1.7.2 and I don't care the
>> least for older versions.  There's no reason to clutter the code to
>> support old, unsupported Cygwin versions.  There are existing, older
>> builds of libiconv available for them.
> 
> But I'm not (really) talking about libiconv. I'm talking about a
> proposed patch for gnulib -- which is a *source based repository* meant
> to be imported *as source* into other projects, so there are no "old
> builds" of gnulib.  So, it's a policy question for the gnulib
> maintainers: what is their "too old; we don't care" horizon for cygwin?

> Eric (Blake), you're active on the gnulib list. Care to comment?

Answering with my gnulib maintainer hat on (and yes, I am one of the
core gnulib maintainers) - Bruno Haible likes to keep cygwin 1.5
supported in gnulib, and probably will do until at least 3 years after
cygwin 1.7 was first released, since it is still relatively easy to
install cygwin 1.5 alongside a modern cygwin and test patches against
both versions.  But Bruno also tends to be the strongest advocate for
back-compatibility; my feel is that most other active maintainers,
myself included, are concerned with what builds now, but not worrying
about porting to an old distro if upgrading to a newer version of the
same distro achieves the same goal.  Then again, all this progreloc
stuff that triggered this conversation in the first place is Bruno's
domain, so I can pretty much guess the answer - he'll want to support as
much as possible, if such support is easy to do.

Put another way: gnulib will support as many versions of easily
maintainable platforms as possible.  For closed solutions, this means as
long as the vendor will also support it (for example, SunOS 4 is no
longer a viable target, since Sun dropped support for the OS before they
even merged into Oracle), and Solaris 8 is borderline (Oracle doesn't
support it, but it's generally not too hard to support) - there, we have
no control over when the vendor puts out a new version, so we have to
maintain the workaround as long as the vendor maintains the old version.
 For Linux, the window has been back to the oldest shipping
enterprise-level distro (for example, CentOS 5 is a viable porting
target, which puts the window at about 3-5 years for glibc/kernel
workarounds in gnulib).  But in general, for open platforms (Linux,
Cygwin, BSD), the thought has been that for very difficult bugs, where a
portability workaround is more of a maintenance burden than just fixing
the bug upstream, it is better off filing a bug report with the upstream
distro in parallel with the gnulib workaround, so that the workaround
can be retired when the old distros are out of use.

So, answering with my cygwin contributor hat on - it doesn't matter if
we've fixed the bug for cygwin 1.7.8, gnulib will probably want a
solution that works with cygwin 1.7.7 for about the next 3-year window,
as well as a solution for cygwin 1.5.  But that's gnulib's problem, not
cygwin's - don't let it stop us from making progress here.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature