DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=BWsAbHG
	E/nuGVhPfgh/HZdPu2Ulz7+9Kcs6Bmfn0gPg8CpbFoKpdKccpXvb+nLtyYOX0y3z
	GmSGK9s9gX8S7I1BxebFLAC3YCuLA8bZGXAD24B849EZMpLknwezSbEOD7HZjHzP
	VKWHt4wCctFZVBvF0kM58qFhT11pvSai7xak=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
References: <dddf240b-0569-1e28-2e53-a5c833e12644 AT gmail DOT com>
In-Reply-To: <dddf240b-0569-1e28-2e53-a5c833e12644@gmail.com>
From: "E. Madison Bray" <erik DOT m DOT bray AT gmail DOT com>
Date: Tue, 5 Mar 2019 15:07:36 +0100
Message-ID: <CAOTD34ZCHXu0yMNLLhWusM=zq=9S8McHacdwG2DVW+i1R8DQUA@mail.gmail.com>
Subject: Re: cygwin port of glib
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 3, 2019 at 11:07 AM LRN wrote:
>
> Looking at cygwin glib source package, i see a lot of downstream patches
> applied to glib over the years (there are no dates, but the versions range from
> 2.34.3 to 2.50 - that might be as early as 2012 and as late as 2017) to make it
> work correctly on cygwin.
>
> Why are these not upstream (considering the fact that glib does have some
> cygwin-specific code - clearly it's not because glib doesn't *want* cygwin
> compatibility)?
>
> Alternatively, since some of these patches *remove* cygwin-specific code from
> glib (as, apparently, it was aimed at old versions of cygwin), why not ask glib
> maintainers to remove cygwin support completely (which might simplify the
> porting process, since cygwin glib maintainers won't have to guess which parts
> of cygwin-specific code in glib are in working order, and which are not)? Also,
> since cygwin masquerades as a linux-flavoured POSIX platform, a more correct
> approach for glib might be to perform appropriate configure-time checks and
> then use their results to decide which code to compile, instead of blindly
> trusting that a particular piece of code will work on
> bsd/linux/cygwin/whatever. That would remove the need for some of those patches.

Hi,

While I'm not often as eager to "pass the buck" as many open source
contributors are (though I certainly understand the impulse), but in
this case I would suggest that, if you care enough to do it, you
should offer to upstream that they accept some/all of those patches,
as in most cases they may not even be aware it exists. My guess is
that whoever is maintaining the glib package for Cygwin either doesn't
know glib well enough to be able to advocate effectively for those
patches, or doesn't care enough to.

If they're clean, worthwhile patches then I absolutely think you
should get them integrated upstream if at all possible--that's almost
always preferable.  But be warned, it can be a significant time-suck
just to get patches upstream, even on projects that look ostensibly
like they support Cygwin.  From personal experience, I have been
trying to get Cygwin fixes to Python upstream and some of them have
taken *years* to get and multiple rewrites over time, despite being
seemingly simple and uncontroversial.

It's just the nature of working with lots and lots of projects that
have other concerns :(

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple