4 ms·

Interesting (I'm not a kernel developer). What's the workflow at the subsystem level -- does the maintainer do a `git fetch` followed by `git rebase`? Or is the

Interesting (I'm not a kernel developer). What's the workflow at the subsystem level -- does the maintainer do a `git fetch` followed by `git rebase`? Or is the rebasing done via email patches and `git am`?

ajdlinux 11y ago
It's pretty much all done by emailed patches with git am - I maintain a personal tree on GitHub and one privately in my company, but they're purely for experimentation, not for sending pull requests. Email is how we submit code, discuss code and review code. You use git send-email to fire your patches off to the appropriate maintainer + mailing list, you make your modifications/rebase it/etc then send off V2, V3, ... V14 of your patch until everyone's happy. Among other things, we tend to be quite picky about getting commit messages right, and making sure that patch series are "structured" in a "nice" way - so git rebase -i is one of the most common commands I run on my private branches... Maintainers all have their own tools and scripts to help automate and track the whole process - in the area where I work, we track things using Patchwork (see http://patchwork.ozlabs.org/project/linuxppc-dev/list/ http://patchwork.ozlabs.org/project/linuxppc-dev/list/). When the maintainer's happy with a patch, it gets applied and pushed to one of the trees they use (e.g. with powerpc, we have powerpc-next for feature development and powerpc-fixes for important fixes). Eventually, they send Linus a pull request, and it makes its way into the kernel mainline. It's a bit of a tricky system that requires understanding of the kernel community's social norms to get right - which I'm not entirely happy with but I don't think it'll change particularly quickly. However, it's also surprisingly effective - the kernel is one of the largest and most distributed individual projects in the open source world, and as a community we keep pushing out releases.

ajdlinux 11y ago

It's pretty much all done by emailed patches with git am - I maintain a personal tree on GitHub and one privately in my company, but they're purely for experimentation, not for sending pull requests. Email is how we submit code, discuss code and review code. You use git send-email to fire your patches off to the appropriate maintainer + mailing list, you make your modifications/rebase it/etc then send off V2, V3, ... V14 of your patch until everyone's happy. Among other things, we tend to be quite picky about getting commit messages right, and making sure that patch series are "structured" in a "nice" way - so git rebase -i is one of the most common commands I run on my private branches... Maintainers all have their own tools and scripts to help automate and track the whole process - in the area where I work, we track things using Patchwork (see http://patchwork.ozlabs.org/project/linuxppc-dev/list/ http://patchwork.ozlabs.org/project/linuxppc-dev/list/). When the maintainer's happy with a patch, it gets applied and pushed to one of the trees they use (e.g. with powerpc, we have powerpc-next for feature development and powerpc-fixes for important fixes). Eventually, they send Linus a pull request, and it makes its way into the kernel mainline. It's a bit of a tricky system that requires understanding of the kernel community's social norms to get right - which I'm not entirely happy with but I don't think it'll change particularly quickly. However, it's also surprisingly effective - the kernel is one of the largest and most distributed individual projects in the open source world, and as a community we keep pushing out releases.