Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] Point out merged submodule maintainers as better addresses for patches

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:01

"Shawn O. Pearce" [off-list ref] writes:
Junio doesn't directly manage the git-gui or gitk-git subdirectories
within git.git; these are currently managed by other individuals
and then periodically merged to git.git.  Users often send patches
to Junio for these directories when they should be directed at the
current maintainer instead, so we should point out these special
cases in the SubmittingPatches documentation.
This is a good start, but I think it would be good to mention
that contributors should at least Cc: the people who have been
heavily involved in the past in the surrounding area of the code
or documentation (not necessarily the last person who touched
the area) the patch attempts to improve and/or enhance.

Parts of the system are "actively managed" by people other than
me even though they aren't merged with the subtree strategy.
The areas I mentioned in MaintNotes (in 'todo') are:

 - git-svn is generally deferred to Eric, unless the patch is
   truly trivial.

 - Documentation/user-manual.txt is primarily JBF's bailiwick.

 - Nico is the guy around pack generation.

 - Jakub, Luben and Pasky are more familiar than I am with
   gitweb.

In fact, I would rather see any nontrivial patch to be first
sent "To: " such people with "Cc: " the list.  After it has been
improved into a good enough shape in the discussion that follows
(i.e. success stories to back it up, and without regression
reports and objections), I can pick up the last round directly
from the list, or the active maintainer in the area (if exists;
it might be a better wording to call them "subsystem
maintainers") can forward it to me to apply after a final
submission is made.  Sending the final submission to the
subsystem maintainer who forwards it to the higher level is what
the kernel folks regularly do, but I do not think we are large
enough to require such a formality.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help