|
| 1 | +Contributed Software |
| 2 | + |
| 3 | +Although these pieces are available as part of the official git |
| 4 | +source tree, they are in somewhat different status. The |
| 5 | +intention is to keep interesting tools around git here, maybe |
| 6 | +even experimental ones, to give users an easier access to them, |
| 7 | +and to give tools wider exposure, so that they can be improved |
| 8 | +faster. |
| 9 | + |
| 10 | +I am not expecting to touch these myself that much. As far as |
| 11 | +my day-to-day operation is concerned, these subdirectories are |
| 12 | +owned by their respective primary authors. I am willing to help |
| 13 | +if users of these components and the contrib/ subtree "owners" |
| 14 | +have technical/design issues to resolve, but the initiative to |
| 15 | +fix and/or enhance things _must_ be on the side of the subtree |
| 16 | +owners. IOW, I won't be actively looking for bugs and rooms for |
| 17 | +enhancements in them as the git maintainer -- I may only do so |
| 18 | +just as one of the users when I want to scratch my own itch. If |
| 19 | +you have patches to things in contrib/ area, the patch should be |
| 20 | +first sent to the primary author, and then the primary author |
| 21 | +should ack and forward it to me (git pull request is nicer). |
| 22 | +This is the same way as how I have been treating gitk, and to a |
| 23 | +lesser degree various foreign SCM interfaces, so you know the |
| 24 | +drill. |
| 25 | + |
| 26 | +I expect that things that start their life in the contrib/ area |
| 27 | +to graduate out of contrib/ once they mature, either by becoming |
| 28 | +projects on their own, or moving to the toplevel directory. On |
| 29 | +the other hand, I expect I'll be proposing removal of disused |
| 30 | +and inactive ones from time to time. |
| 31 | + |
| 32 | +If you have new things to add to this area, please first propose |
| 33 | +it on the git mailing list, and after a list discussion proves |
| 34 | +there are some general interests (it does not have to be a |
| 35 | +list-wide consensus for a tool targeted to a relatively narrow |
| 36 | +audience -- for example I do not work with projects whose |
| 37 | +upstream is svn, so I have no use for git-svn myself, but it is |
| 38 | +of general interest for people who need to interoperate with SVN |
| 39 | +repositories in a way git-svn works better than git-svnimport), |
| 40 | +submit a patch to create a subdirectory of contrib/ and put your |
| 41 | +stuff there. |
| 42 | + |
| 43 | +-jc |
| 44 | + |
0 commit comments