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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
