X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-6.8 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4D41D1A1.8040607@redhat.com>
Date: Thu, 27 Jan 2011 13:12:17 -0700
From: Eric Blake <eblake AT redhat DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin patches for gnulib relocation code [Was: Re: Bug in libiconv?]
References: <20110124154158 DOT GA15279 AT calimero DOT vinschen DOT de> <4D3E3EF6 DOT 7010501 AT cwilson DOT fastmail DOT fm> <4D40E1EB DOT 8030401 AT cwilson DOT fastmail DOT fm> <20110127122015 DOT GA25883 AT calimero DOT vinschen DOT de> <4D419B91 DOT 7090005 AT cwilson DOT fastmail DOT fm> <20110127170815 DOT GR28470 AT calimero DOT vinschen DOT de> <4D41BB0E DOT 7020903 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4D41BB0E.7020903@cwilson.fastmail.fm>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9FFF1BDDE21ACE724B7935A1"
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

--------------enig9FFF1BDDE21ACE724B7935A1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.
>=20
>> 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.
>=20
> 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.

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


--------------enig9FFF1BDDE21ACE724B7935A1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNQdGiAAoJEKeha0olJ0NqKdsH/0rfWnW8a69VJ+RutzLIZMC2
90NP7yuQaYFive17SwAGczpa4YQMyIGoHzl0pLrtSZouwa/OomOd/pJEcBb1ZBbo
wMnuojlctyo/Kwv7CtlQ78/eJYvARHWK97poahmwRiKIPo0wNzOKX3b+nmzKMrO2
/Jderq9h8WvhNwC4p4mepk6rNzHCpK8fy3G9FK50734GLGZtgyrhfHLDRX//h6kD
d8OV9kivdXhFxGv8JZ/czY/P97durJQcwfBCD6jymM+GToykn6MEecT92Kal/0v2
bOx1ctfFRIOsAZN+eBAK4d60sP/3ZmEmgvTdU+lVJjJ5o6B1otl/W2bTkjoK02Q=
=kYAU
-----END PGP SIGNATURE-----

--------------enig9FFF1BDDE21ACE724B7935A1--