On 20/03, Arnaud Charlet wrote: | > Since 2007-12-19, which is the date of the latest AdaCore batch | > merge (three months ago), the Ada front end has only received the | > following patches: | > | > - platform-specific and build-related patches | > | > - gigi (Ada structures -> GCC structures) patches from Éric Botcazou | > in *.c files | | In addition, Eric's changes are definitely part of AdaCore's regular | synchronizations to the FSF tree, and these represent quite a few critical | changes. So your impression that "no changes have been made to the FSF tree by | AdaCore for 3 monthes" is incorrect.
Éric patches hardly belong to what I call "AdaCore batch merges", that is: - large merges done in a very short period of time - no corresponding test cases or non-regression tests - no reference to existing PR - no closing of corresponding bugzilla entries As a consequence, the last two items require that other people retest the Ada bugs in bugzilla and close them if they happen to have been fixed by chance by the last jumbo merge. If people don't do that, the bugzilla is clogged with old useless entries and those volunteering to fix Ada bugs in GCC (as I do) lose a lot of time figuring out which bug they should work on and whether it is still relevant or not. Éric patches do reference PR and add corresponding tests, as is done in the rest of GCC and as yourself require before accepting contributed patches for the Ada front-end. Doing a egrep '(adacore.com|act-europe.fr|gnat.com)' gcc/testsuite/ChangeLog and comparing this to the gcc/ada/ChangeLog speaks for itself. So no, I was definitely not talking about Éric patches when writing about "AdaCore batch merges". Moreover, either you consider that Éric changes are part of the Ada front-end and this means that it was possible to get changes in, or you consider that they are not part of the front-end (but rather the middle-end) which means that the front-end is really stalled. | As I said, I am working on putting many changes at the FSF tree right now, | which should happen within the next few weeks, and for a week or so, since there | are many patches to test and incorporate. That is in itself good news. | I hope this clarifies things. This partially explains why external patches were not approved, but this doesn't explain why they didn't receive *any* feedback in a reasonable time. I certainly appreciate all the very high quality support I get from AdaCore when working on fixing a bug in GNAT or trying to get a new feature in, they have always been of tremendous help and it is always a real pleasure to work with them. What I am disatisfied with is the way Ada front-end maintainers for the FSF GNAT tree have been handling (or rather not handling) patches for a few months without any explanation and how large changes are pushed in without taking care of proper GCC procedures. Maybe you think that there is no problem here, but from a volunteering contributor point of view, there is. Sam
