[plug] Kernel development process

[Andrew Cooks]

Hi Jeremy,

On Fri, Jul 13, 2012 at 1:54 PM, Jeremy Kerr <jk at ozlabs.org> wrote:
>
> As well as the other good reasons given in this thread, the aspect of patch
> review is pretty important. If patches are sent to a list (rather than
> provided in a git repository), then there's a very low barrier for anyone on
> the list to review and comment on the patches. The emails are already in a
> format that makes it easy to reply and provide feedback, rather than having
> to clone a repo, and manually create replies.
>
> You'll often see large changesets posted to the list as patches, but also
> include a git URL for easier merging.
>
> Of all of the "procedures" of kernel development, thorough review is
> something we try to optimise for. The easier it is to review a proposed
> change, the better.
>

Thanks, that makes sense. So far I've found that I usually need more
context than the patch provides and end up in git and vim anyway (it
just takes longer to get into things when you've only got 4-8 hours
per week to spend on it, as opposed to 35-45 hours). Commenting isn't
something I've experienced much. Up to now I've used tracking branches
to get the changes I'm interested in and in the case of a bug report
I'd refer to a git commit, rather than trying to find the message
where the patch was submitted.

It's quite a different experience to follow a piece of the kernel
under active development (IOMMU, DMAR), than to be working on some
driver that will never be submitted, on one specific version, at an
employer that would rather not be named (and I'm sure there's a lot of
the latter going on around the world).

Cheers!

a.