Message-ID: <20130118221614.GA5616@ppwaskie-mobl2.amr.corp.intel.com>
Date:	Fri, 18 Jan 2013 14:16:14 -0800
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Tom St Denis <tstdenis@...iptictech.com>
Cc:	David Miller <davem@...emloft.net>,
	steffen klassert <steffen.klassert@...unet.com>,
	herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: IPsec AH use of ahash

On Fri, Jan 18, 2013 at 03:53:44PM -0500, Tom St Denis wrote:
> Admittedly I'm new to the kernel scene but what exactly is a "maintainer" then?

Maintainers are ultimately responsible for content that flows into a tree
or subsystem.  That means they must command a level of expertise on
everything about the code they maintain to decide what goes in and what
doesn't.  This doesn't mean they know everything about everything, but
their judgement is built on experience and time in the job.

> Suppose I invest time to re-write the IPv4/v6 AH code to correctly use AEAD instead of ahash, to then perform the testing required, etc... do I get credit as a maintainer in the IPsec tree?

Working on a single thing doesn't make you a maintainer, it makes you a
contributor.  There are vastly more contributors than maintainers, and that's
how it should be.  A maintainer depends on contributors to be the people
in the trenches dealing with the specifics of things like the AH code, in
this case.  However, a maintainer's signed-off-by on a contributor's code
also makes the maintainer accountable for the code being included in the
kernel.  This is not something to be taken lightly.

> I'm also a little annoyed that my CMAC patch was rejected for among other reasons that it violated "coding standards."  Specially since it was almost entirely copied from crypto/xcbc.c which also violates the same rules.  As a newcomer to the tree I tried my best by emulating readily available code (which apparently was already accepted into the tree) to then just get shot down for attempting to contribute.  If my CMAC code is not good enough for the tree I humbly suggest you also remove the XCBC code too while we're at it.

I would recommend just hanging out on the netdev list and read it for a few
days.  There are a *large* number of patches that are critiqued and asked
to either be rewritten, modified, or dropped.  The whole point of the
community is to share your work and code, and then either defend the code,
or incorporate feedback and resubmit.  Many patches take multiple spins before
they're applied.  It's the nature of the community.

Note that quite a bit of code has been in the kernel for a long time.  There
will be examples of code that doesn't conform; there are millions of lines of
code in Linux, nothing is going to be perfect.  If you find your code doesn't
meet a coding standard, then respin the patch, and then use that opportunity
to fix the other code you've seen to meet the coding standard.  That's two
contributions that only improve the kernel, and increases your credibility
as an active contributor.

> What I would expect from the "maintainers" is that they actually take on a more than trivial involvement in the progress of the code.  If I have to create original content and massage it into whatever form pleases the owners of the tree am I not the maintainer of the code?  I was honestly expecting someone with more involvement in the tree to move the [in this case] CMAC patch forward.  

I'd suggest you go look at patchwork.ozlabs.org and look at the queues of
patches that various maintainers are juggling.  Maintainers offer feedback and
review when they can, but they rely on other contributors to really vet the
code.  And the fact that David responded at all shouldn't be viewed as
trivial involvement, he's one of the most busy maintainers in the kernel.

Cheers,
-PJ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists