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

[Jacob Carlborg]

On 6 mar 2011, at 20:10, 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.


The process of the applying patches to the Linux kernel is, If I undertand it correctly, something like this:

1. First someone submits a patch for, let say, a network related problem
2. Then one of the kernel developers, that probably don't trust the person who submitted that patch and probably doesn't even know how it is, reviews the patch, applies it to his/her own repository of the kernel and tests it
3. The developer at step 2 ask another developer, above him/her, to pull from his/her repository
4. Now at this stage the second developer probably trusts the first developer but checks the code anyway and merges it with his/her own
5. Step 3-4 are repeated a couple of times and more code is added to the original pull request with other patches
6. Now Linus receives a pull request from one of the developers, probably the one responsibly for, in this example, the network related code or someone even higher up the hierarchy. This patch is probably just one among many other patches that Linus receives in the pull request and he doesn't care about this patch alone. He definitely doesn't trust the person how original submitted the patch and the first person who reviewed it but he trusts the person next to him, that he received the pull request from. The person Linus received the pull request doesn't either trust the original submitter but he trusts the person he received the pull request from and so on.
7. The next step for Linus just to merge, probably by now, this big pull request
8. If something goes wrong, any conflicts occurred while merge, Linus doesn't resolve them, he just say to the person he received the pull request form: "hey, I got a conflict when merging your pull request, fix it".
9. It then goes pack down the hierarchy to some level where someone fix the merge conflict and it all starts over

This is how I understand it after watching the Google talk Linus had about git.

-- 
/Jacob Carlborg