Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Simon Wright <simon@pushface.org>]

Paul Rubin <no.email@nospam.invalid> writes:

> Simon Wright <simon@pushface.org> writes:
>> I'm far from expert on GCC procedures, but all three of the Ada
>> front-end maintainers (see [1]) are AdaCore employees, and I don't
>> think you're going to get approval for updates to Ada internals from
>> anyone else.
>
> Unless you've got some particular reason to believe that (e.g. based
> on experience submitting patches), I tend to be skeptical.  Most FOSS
> projects love getting good patches (patches that work, are tested,
> conform to the project's standards and interfaces, etc.)  What they
> don't like is "homework assignments", i.e. someone else coming along
> and telling them to do some work (unless they are a paying customer of
> course).
>
> I haven't been involved with GNAT at all, but I've contributed to GCC
> and have found the maintainers to generally be receptive to patches
> where the submitter is the one who does the work, and they're at least
> somewhat willing to advise about what work is needed.  What they don't
> want is "please implement feature X" or even "here is my crappy patch,
> please clean it up, test it, rework it so it fits the rest of the
> codebase, etc., all for free".  That's what support contracts are for.
>
> When it's a clean patch that really improves things and includes all
> necessary documentation and tests, it is usually smooth sailing.

A patch that fixes a bootstrap-preventing ICE on Darwin is (a) likely
not to be in the Ada internals even if it's in the Ada directories, (b)
equally likely to be discussed/accepted by Darwin maintainers as by Ada
maintainers.

A small patch that fixed a wide character encoding problem was approved
but the identical patch actually applied (some time later) was
originated by an AdaCore employee. (I was miffed about this, you can
tell)

A patch that fixed an ICE was rejected because AdaCore had a better fix
in mind for their own source tree (I can see there may well be
fork-related issues here). Aside from the hairy nature of the compiler
internals, this is my main reason for not trying to add features to the
compiler: AdaCore have a development plan that we aren't party to, and
almost any change could be affected. Also, I have quite enough to
interest me anyway!