public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathanael Nerode <neroden@twcny.rr.com>
To: gcc@gcc.gnu.org, stl@caltech.edu
Subject: Re: MinGW (Was Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)
Date: Tue, 20 May 2003 01:24:00 -0000	[thread overview]
Message-ID: <20030520011613.GA629@doctormoo> (raw)

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

             reply	other threads:[~2003-05-20  1:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-20  1:24 Nathanael Nerode [this message]
2003-05-21  3:33 ` Christopher Faylor
  -- strict thread matches above, loose matches on Subject: below --
2003-05-20 17:52 MinGW (Was: " Bonzini
2003-05-20  1:16 Stephan T. Lavavej
2003-05-20  4:27 ` Ranjit Mathew
2003-05-20 16:15 ` E. Weddington
2003-05-19 22:40 Stephan T. Lavavej
2003-05-19 23:49 ` Joe Buck
2003-05-20  0:33 ` DJ Delorie
2003-05-21  3:27   ` Christopher Faylor
2003-05-20  4:22 ` Anthony Green

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030520011613.GA629@doctormoo \
    --to=neroden@twcny.rr.com \
    --cc=gcc@gcc.gnu.org \
    --cc=stl@caltech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).