Handling of compiler patches

[bearophile]

For DMD in GitHub there are more than one hundred open pull 
requests (currently 111). So far people have created more than 
one thousand patches for DMD (currently 1022):

https://github.com/D-Programming-Language/dmd/pulls

Among the list of open pull requests there are some bugs and 
enhancement requests that I'd really like to see applied & fixed 
in not too much time.

I am not a compiler writer, but I have two suggestions for Walter 
(or at least to open a discussion, if the things I am saying are 
wrong):

1) Currently the patches that Walter applies written by other 
people come mostly from the most recent ones. So the list of the 
open pull requests is managed almost as a stack (last in - fist 
out). I think this is not good.

I suggest to do the opposite, this means to manage that list more 
like a queue (first in - first out), so I suggest Walter to look 
for patches to apply starting from the oldest ones. This has the 
advantage that the patches don't get too much old, so they rot 
less.

An additional strategy to choose what patches to apply is to 
choose first the ones that fix bugs that are most significant. 
Bugs are not all equal, many bugs don't cause significant 
problems, while others are quite annoying. Significant bugs often 
are fixed by small patches. I see lot of not so significant 
patches applied, while I see patches that fix bugs that I hit 
every other day sleep in that list for weeks or months. If you 
want I will list some significant patches currently open.


2) I suggest Walter to increase a little more the openness of the 
way the front-end is developed. There are many kinds of compiler 
patches:

- Simple localized change;
- Complex localized change;
- Widespread trivial changes;
- Widespread complex changes;
- Back-end changes Vs front-end changes;
- That fixes a well defined and localized bug;
- That introduces a new feature, or a small part of a new feature.

The harder patches are better left to Walter, but I suggest 
Walter to eventually let few other people merge the simpler 
patches, after a review by one or two more persons.

In large projects, with skilled helper people, the leader 
eventually must learn to trust other people and to  delegate some 
of the work, building a pyramid of trust. I think that if Hara 
writes a simple 5-lines long patch for the DMD front-end, and Don 
or someone else equally skilled reviews and accepts that patch, 
there is no need for Walter to merge that little patch himself.

Bye,
bearophile