Re: MinGW (Was Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Nathanael Nerode <neroden at twcny dot rr dot com>]

Stephan T. Lavavej said:

>The message here is interesting:
>http://sourceforge.net/mailarchive/forum.php?thread_id=2280276&forum_id=5119
>
>[Danny R. Smith] 
>> The idea is to get all the ming and cygwin local changes into 
>> mainstream FSF CVS, so that there is no need for a branch.
>> We are getting there.
>> Mingw Java developers have been particularly active and the ReactOs
>> people have also added a fair chunk.
>
>>> I see these GCC .diff files for every MinGW GCC release.
>>> Where are they coming from?
>>> On a maintainer's hard drive, perhaps? =)
>
>> Yes, mine, for now.
>> But that is not satisfactory from my point of view either.  
>
>>> What specifically keeps these patches from being committed?
> 
>> Time. Also, many heavy gcc developers have more importnat things to
>> review than patches for an unsupported platform like mingw. 
>> Cygwin, at least, is considered a secondary platform.

Patches not getting reviewed in a reasonable amount of time is a known 
problem, and we're all working on it.  :-/

If the patches aren't submitted to gcc-patches@gcc.gnu.org, we can't do 
anything, though.

If they are submitted and get no review in about two weeks, the 
submitter should send a message titled 'unreviewed patch'... that usually
gets people's attention.

There are two types of changes:

* MinGW-specific support changes, which don't affect anyone not using 
MinGW.  For these, we'd probably accept the word of the MinGW developers 
to a certain extent, since they're the experts.  I don't see any reason 
why these wouldn't go in quickly, except really sloppy coding, use of 
deprecated or obsolete constructs, or lack of documentation.

* Changes which may affect builds for other platforms as well.  These 
have to be reviewed quite carefully, of course, but are very welcome 
especially if they're bug fixes.  :-)

--Nathanael