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

[Don Clugston]

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.