On Fri, Nov 22, 2013 at 12:25 PM, David Howells <dhowe...@redhat.com> wrote:
> Linus Torvalds <torva...@linux-foundation.org> wrote:
>
>> So for future cases: if there are big independent overhauls of core
>> subsystems, I'd really like to see them kept separate, ok?
>
> Since the trusted and encrypted keys that Mimi and Dmitry deal with are also
> more akin to the keyring stuff, should they go through the keyring branch?
> And does James want to hold that branch?
So by now, the changes are hopefully smaller and general "updates"
rather than big new features. At that point, I don't care too deeply.
It's the "this is a whole new big way of doing things, and there's
fundamental new core code" that I would really like to be able to see
separately in order to make it much easier for me to pull and walk
through independently of the normal "updates to subsystem" stuff.
> I wrote it in userspace where I could easily drive it with huge numbers of
> entries (add a million keys, say, delete them randomly and check at each step
> that each remaining key can still be found) and also valground it. For
> reference, what's the best way of showing you something like this?
Quite frankly, I just want to *know* about things like this, there
doesn't have to be some fixed format for it.
It can be part of the pull request, explaining where the code comes
from, how it's been tested, who has looked at it etc etc. Or it can be
just free-form in the commit messages.
And again, this - for me - is about core code that isn't deeply
embedded in some internal subsystem. So the reason I reacted to the
assoc_array.c thing is that it was clearly set up to be generic, and
it does end up being pretty different and affects "normal" users. So I
go off looking for "ok, where can I find this discussed" for doing
some minimal due diligence on a new set of core code, and I find very
little on lkml, and nothing else. And the commit message talks about
what it does, but not about the "who looked at it", so I basically had
nothing to judge it by except just looking at the code.
Which didn't look horrible, but it really would have made me happier
hearing about people looking it over, and about you testing it in user
space etc etc.
> I did show it to Paul McKenney - and he gave me some comments on it, though I
> didn't ask for a Reviewed-by line, which in retrospect I should've done.
>
> Should we have a "Comments-from: x <y@z>" line for this? So that people who
> made comments but don't want to say they've properly reviewed it can be
> recognised formally?
A "reviewed-by" line is fine, but so is really just free-form explanations too.
Not everything has to be a "xyz-by:" thing, especially things that are
more important for one-time use at merge time rather than anything
"this is a common pattern and people might want to do statistics about
it over time".
It's too late for this case, and for all I know there are no similar
cases coming up in the security layer, but when I have something that
ends up being pending for a two weeks, I want to at least try to
educate people about *why* it was pending, and what I found difficult
about the process. Maybe it happens again, maybe it won't. But if it
does, we'll have at least spoken about the issues.
> Is there some way in the GIT repo to associate an 'extended explanation' with
> several patches?
In theory, you can use notes, but I don't actually like it either
technically _or_ from a "flow of information" standpoint, so I'd much
rather see people try to note things in the commit messages, and then
for the merge itself try to have explanations in the "please pull"
message.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
