Handling of compiler patches

[Andrea Fontana]

+1

On Thursday, 21 June 2012 at 07:40:35 UTC, bearophile wrote:
> 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