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
next 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).