https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Kaz Kylheku from comment #11) > I deployed that change to large team of developers, and the toolchain with > that change went to customers also. The warning caught problems that were > fixed and didn't appear to break anything. If the patch were to be upstreamed, it will be reviewed, regression tests would be added to make sure it doesn't silently break, and your customers could update to newer versions of GCC without losing the warning. > Today, I no longer care about upstreaming code to OSS projects because of > prima donna attitudes like this. It's just too much effort dealing with the > barriers. > > In my own projects, I accept good patches, even if they are written on a > grease-stained napkin. Perhaps your project is of a size that your team can do this. This is not the case in large free-software projects, which all have much more pending work to do than people to do it. We already have trouble keeping up with the reviews of the patches people submit following the proper procedure (just subscribe to gcc-patches and try to read all that is going on there), which is supposed to favour quality and future maintainability rather than quantity and quick development. We do not have enough people with enough time to confirm all the bug reports that are submitted (subscribe to gcc-bugs if you are brave enough). Thus, if something is not critical, you do not actively pursue it and the active developers have something more interesting or urgent to work on, your patch may be ignored, even if you follow the proper procedures. See https://gcc.gnu.org/wiki/Community (The above is not a statement about whether the current procedures are ideal or even beneficial. It is just a description of the status-quo, which seems to work for the people who contribute patches every day to GCC, even if it doesn't work so well for people that contribute only sporadically).
