[dmd-internals] open dmd pull requests, oldest Feb 6, 2011

[Benjamin Shropshire]

On 03/06/2011 11:49 AM, Walter Bright wrote:
>
>
> Don Clugston wrote:
>> On 6 March 2011 07:43, Walter Bright <walter at digitalmars.com> wrote:
>>> I know, I know, but this piles up faster and faster. 8 new bugzilla 
>>> reports
>>> just today. Many come with patches. I fixed one.
>>
>> Does everyone know about github's Fork Queue? I think it is excellent.
>> It is particularly great for cherry-picking commits.
>> (Eg, if everything in a pull request is trivially correct, except one
>> which needs more thought, use it to merge in everything except the
>> difficult one.
>> Takes just a few seconds).
>>
>> Let's try to analyze the problem a bit more. Where is bottleneck,
>> exactly? Linus Torvalds manages to merge an incredible number of
>> patches per year.
>> So I don't think the sheer number of patches themselves is the issue.
>>
>> Is it evaluating them? If so, it that because the patches don't have
>> adequate explanation?
>> Is it because you don't have evidence to trust the contributor has
>> enough knowledge to make a correct patch? This could be partially
>> overcome by having a regular reliable patcher (eg, me or Rainer) check
>> them first. Maybe there's other things we can do.
>>
>>
>> But if the bottleneck isn't the evaluation, then I think you're just
>> doing too much work. You  just need to use a binary approach: accept
>> without modifications, or reject.
>> EG.  Looks correct but... Please add unit tests. Please include D1
>> version. Please fix formatting.
>>
>> Because really, if a patch is OK, the actions can be as simple as:
>> - merge with ForkQueue.
>> - switch to dmd1-x branch. Merge with ForkQueue.
>>
>> Then after integrating a huge raft of changes, if all tests pass, add
>> to the changelog. If a failure occurs, revert them.
>>
>> Pull requester can be responsible for marking Bugzilla with the fix.
>>
>> If you integrate good patches very quickly, it'll be OK to be have
>> fairly harsh rules about them.
>>
>> OTOH I don't know what to about the const(Object) ref pull request.
>> That will definitely take a long time to evaluate.
>
> One problem is evaluating what should be done about D1. I'll evaluate 
> if and how they should be folded into D1, then merge, test with D1, 
> update D1 test suite, etc. Not a huge problem, but time consuming.
>
> (With your last patch list, I just could not get the merge to work 
> automatically for D1, I went and did it manually.)
>
> Probably the largest problem is just the context switch. When I'm 
> working on, say, 64 bit code gen it's hard to look at other parts of 
> the code. Right now I'm trying to figure out how to integrate in 
> destructor calls for temporaries.

A bit more visibility into the process might help the situation. Even 
just flagging anything you look at with boiler plate comments might do 
it. If nothing else,  no news, could be good news.