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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 27, 2007, 04:37 UTC
Message-ID: <7v1w98kb29.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071227041220.GA22256@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 6 quoted lines

> 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.