Handling of compiler patches

Trass3r un at known.com
Thu Jun 21 06:23:35 PDT 2012


> 1) Currently the patches that Walter applies written by other people  
> come mostly from the most recent ones. I think this is not good.

Yep, github's default sort method sucks.
They should really implement some sort of voting scheme or something like  
a "ready to merge" button for prolific contributors.

Interestingly enough they even seem to have a 'votes' field for pull  
requests internally (http://develop.github.com/p/pulls.html) but I haven't  
seen any voting system yet.


> 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.

+1
It's just annoying having to keep pull requests up-to-date forever.

AND it definitely pisses contributors off. At least I won't submit  
anything anymore if the pulls just rot anyways.


Also I really wonder if Walter's using the autotester.
Most patches are ridiculously small and/or non-critical, so reviewing the  
code by hand can't take that long.
And if you properly use the autotester instead of manually running the  
testsuite to verify it doesn't break anything you should really be able to  
merge a whole bunch of pulls in no time.

Why is the process still so slow?


More information about the Digitalmars-d mailing list