> - 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
I'm sorry, but that's simply wrong. Test cases are posted, and when suitable, are added to the test suite. PR are referenced when such reference is known. Correpsonding bugzilla entries are closed (I have closed dozens of bugzilla entries in the past). You have probably been unlucky to stumble into a few cases where a fix was made that was done in parallel to an existing PR and thus, the PR was not closed at the same time, but when a fix is known to address a PR, it is mentioned and the PR is closed. > Moreover, either you consider that Éric changes are part of the Ada > front-end Definitely. > and this means that it was possible to get changes in, or you Eric, as others, had to delay his changes during batch 3 and has only recently done these changes. Since the number of changes I am handling is much larger, this takes some more time, and the few Ada breakages have also caused additional delays. > 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 Maybe that's partly because you are not following closely the development of GCC and are not familiar with the GCC stages. Submitting patches during stage3 (in particular end of stage3) is not really the most appropriate time, so it's often better to wait for stage 1 or stage 2 for such submissions. > and how large changes are pushed in without taking care of proper GCC > procedures. That's really unfair, our procedures for merging try to be as close as possible to "proper" GCC procedures. Arno
