3 ms·

Man, now I feel like a total hack. I love the github pull request. I do insist that my devs use a good style (i.e. first line is a summary and wrap at 80 chars)

Man, now I feel like a total hack. I love the github pull request. I do insist that my devs use a good style (i.e. first line is a summary and wrap at 80 chars) but I love the user interface for looking at diffs and doing a code review. I had no idea it was inferior until reading this and now I find myself in the awkward position that I don't care. Have I really become the guy who values an efficient team process more that adherence to esoteric specifications. God, I can't believe it's come to that.

ajross 14y ago
The pull request as a mechanism for "here are some changes to look at" for a small project isn't the same thing as "Here are the USB stack changes for the 3.4 merge window". The kernel has a mature, rigorous and well-defined development process[1]. Things that don't fit well into that model just aren't going to be successful, even if they work well in other contexts. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/development-process http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git...
- ajross 14y ago
  It's also worth pointing out that the "pull request" in question here was a 2-liner addition of a USB device ID that should have gone to a subsystem maintainer anyway.
geoffhill 14y ago
Don't sweat it; Linus's needs are far different from the rest of us. We're talking about the guy here who made Git just to have a tool that perfectly conformed to his ideal kernel development process. Since his job is basically to be a full-time pull request approver, it makes sense that he would be extremely specific about the format to improve his efficiency.
oijaf888 14y ago
I doubt your devs number as many as the kernel contributors nor are they working as independently. Perhaps "esoteric specifications" exist for a reason on a massive project which has seen and tried many things in the past 20 years. If your devs commit bad code its probably pretty easy for you to find them and possibly fire them. If you can't tell who a kernel patch is from or even if it is actually from the person specified it calls into question the security of the kernel.

ajross 14y ago

The pull request as a mechanism for "here are some changes to look at" for a small project isn't the same thing as "Here are the USB stack changes for the 3.4 merge window". The kernel has a mature, rigorous and well-defined development process[1]. Things that don't fit well into that model just aren't going to be successful, even if they work well in other contexts. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/development-process http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git...

ajross 14y ago
It's also worth pointing out that the "pull request" in question here was a 2-liner addition of a USB device ID that should have gone to a subsystem maintainer anyway.

geoffhill 14y ago

Don't sweat it; Linus's needs are far different from the rest of us. We're talking about the guy here who made Git just to have a tool that perfectly conformed to his ideal kernel development process. Since his job is basically to be a full-time pull request approver, it makes sense that he would be extremely specific about the format to improve his efficiency.

oijaf888 14y ago

I doubt your devs number as many as the kernel contributors nor are they working as independently. Perhaps "esoteric specifications" exist for a reason on a massive project which has seen and tried many things in the past 20 years. If your devs commit bad code its probably pretty easy for you to find them and possibly fire them. If you can't tell who a kernel patch is from or even if it is actually from the person specified it calls into question the security of the kernel.