patch, 2 partsProvide better guidance for submitting patches against git-gui, gitk

I spent a good amount of time yesterday figuring out the correct workflow to submit a change to gitk. As I understand it, gitk (and I think git-gui) are maintained upstream of git, and patches should be sent to the git email list against the upstream repo. I think a top-level MAINTAINERS file would help new contributers like me get orientated, especially in the cases of these upstream projects that require a somewhat non-standard workflow

I also added some additional clarifications to SubmittingPatches that clarifies the additional steps required to submit patches against the guis.

Please double check that I've got the correct email addresses and canonical repositories

I'm guessing there are additional Maintainers who should be added to the MAINTAINERS file, I just haven't followed to email list closely enough to know all the formal/informal workflows that should be observed.

Jason Holden (2):
  Add top-level maintainers file with email/canonical repository
    information
  Provide better guidance for submitting patches against git-gui, gitk

 Documentation/SubmittingPatches | 11 +++++++++++
 MAINTAINERS                     | 17 +++++++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 MAINTAINERS

Certain parts of git have a semi-formalized workflow for incoming patches. This file documents the maintainers, their area of specialization, their email address, and their canonical repository against which patches should be submitted.

Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
 MAINTAINERS | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 MAINTAINERS

git-gui and gitk are maintained upstream of git. Document this, and the procedure for submitting patches to these tools

Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
 Documentation/SubmittingPatches | 11 +++++++++++
 1 file changed, 11 insertions(+)

Jason Holden <jason.k.holden.swdev@gmail.com> writes:

Thanks; I just realized that nothing in Documentation/ hierarchy mentions these; they are only mentioned in "A Note from the Maintainer" I send out every once in a while (kept in MaintNotes of 'todo' branch):

    * Other people's trees, trusted lieutenants and credits.

    Documentation/SubmittingPatches outlines to whom your proposed changes
    should be sent.  As described in contrib/README, I would delegate fixes
    and enhancements in contrib/ area to the primary contributors of them.

    Although the following are included in git.git repository, they have their
    own authoritative repository and maintainers:

     - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

            git://repo.or.cz/git-gui.git

     - gitk-git/ comes from Paul Mackerras's gitk project:

            git://ozlabs.org/~paulus/gitk

     - po/ comes from the localization coordinator, Jiang Xin:

            https://github.com/git-l10n/git-po/

Perhaps the update should mention po/ as well?

Junio C Hamano <gitster <at> pobox.com> writes:

Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation?

--- Thomas

On Mon, Dec 31, 2012 at 09:40:19AM +0000, Thomas Ackermann wrote:

Putting it in Documentation/ would add one more outlier file (Along w/ SubmittingPatches and CodingGuidelines). Documentation/technical seems too deep. I've got a patch that incorporates the content into the existing README, but that seems a bit out of place, as the previous content of README was primarily pointers to other docs.

What about a README.developers at the toplevel?

Thomas Ackermann <th.acker@arcor.de> writes:

Perhaps. It started as a living document that discusses the state of affairs as of the time of posting (there are mentions to "the most recent such release was ...", etc), and because I wanted to keep it that way (and also I needed somewhere to keep track of it), I deliberately kept it outside the source tree.

It is an addendum to howto-maintain-git, and what it covers overlaps with it, so it will need some clean-ups if we want to go the route you suggest.

Having said all that, I think it is still a good idea to keep the occasional "A note from he Maintainer" posting on list, and a version that needs to rever to another document after losing overlaps with howto-maintain-git will no longer will be suitable source for it, so...