AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity

docs: README.commits converted to markdown

Browse Source
This commit is contained in:
Robert Roth 2018-08-26 23:48:51 +00:00 committed by Matthias Clasen
parent 369cb702e4
commit 4ed4b4fd6a
2 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
CONTRIBUTING.md
View File

@ -48,9 +48,9 @@ $ ninja
``` ```
**Note**: For information about submitting patches and pushing changes **Note**: For information about submitting patches and pushing changes
to Git, see the `README.md` and `README.commits` files. In particular, to Git, see the [README.md](./README.md) and [README.commits.md](./README.commits.md) files. In particular,
don't, under any circumstances, push anything to Git before reading and don't, under any circumstances, push anything to Git before reading and
understanding `README.commmits`. understanding [README.commits.md](./README.commits.md).
Typically, you should work on your own branch: Typically, you should work on your own branch:
@ -60,6 +60,6 @@ $ git checkout -b your-branch
Once you've finished working on the bug fix or feature, push the branch Once you've finished working on the bug fix or feature, push the branch
to the Git repository and open a new merge request, to let the GTK to the Git repository and open a new merge request, to let the GTK
maintainers review your contribution. The [CODE-OWNERS](./docs-CODE-OWNERS) maintainers review your contribution. The [CODE-OWNERS](./docs/CODE-OWNERS)
document contains the list of core contributors to GTK and the areas for document contains the list of core contributors to GTK and the areas for
which they are responsible. which they are responsible.

17
README.commits → README.commits.md
View File

@ -7,25 +7,23 @@ avoid unnecessary breakage, and to take advantage of the knowledge
about GTK+ that has been built up over the years, we'd like to ask about GTK+ that has been built up over the years, we'd like to ask
people committing to GTK+ to follow a few rules: people committing to GTK+ to follow a few rules:
0) Ask first. If your changes are major, or could possibly break existing 0. Ask first. If your changes are major, or could possibly break existing
code, you should always ask. If your change is minor and you've code, you should always ask. If your change is minor and you've
been working on GTK+ for a while it probably isn't necessary been working on GTK+ for a while it probably isn't necessary
to ask. But when in doubt, ask. Even if your change is correct, to ask. But when in doubt, ask. Even if your change is correct,
somebody may know a better way to do things. somebody may know a better way to do things.
If you are making changes to GTK+, you should be subscribed If you are making changes to GTK+, you should be subscribed
to gtk-devel-list@gnome.org. (Subscription address: to gtk-devel-list@gnome.org. (Subscription address:
gtk-devel-list-request@gnome.org.) This is a good place to ask gtk-devel-list-request@gnome.org.) This is a good place to ask
about intended changes. about intended changes.
#gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...) #gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
is also a good place to find GTK+ developers to discuss changes with, is also a good place to find GTK+ developers to discuss changes with,
however, email to gtk-devel-list is the most certain and preferred however, email to gtk-devel-list is the most certain and preferred
method. method.
1) Ask _first_. 0. Ask _first_.
2) With git, we no longer maintain a ChangeLog file, but you are expected 0. With git, we no longer maintain a ChangeLog file, but you are expected
to produce a meaningful commit message. Changes without a sufficient to produce a meaningful commit message. Changes without a sufficient
commit message will be reverted. See below for the expected format commit message will be reverted. See below for the expected format
of commit messages. of commit messages.
@ -39,13 +37,13 @@ Notes:
* The expected format for git commit messages is as follows: * The expected format for git commit messages is as follows:
=== begin example commit === ```
Short explanation of the commit Short explanation of the commit
Longer explanation explaining exactly what's changed, whether any Longer explanation explaining exactly what's changed, whether any
external or private interfaces changed, what bugs were fixed (with bug external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too brief. tracker reference if applicable) and so forth. Be concise but not too brief.
=== end example commit === ```
- Always add a brief description of the commit to the _first_ line of - Always add a brief description of the commit to the _first_ line of
the commit and terminate by two newlines (it will work without the the commit and terminate by two newlines (it will work without the
@ -60,8 +58,8 @@ tracker reference if applicable) and so forth. Be concise but not too brief.
punctuation and capital letters where appropriate. Normally, for patches punctuation and capital letters where appropriate. Normally, for patches
sent to a mailing list it's copied from there. sent to a mailing list it's copied from there.
- When committing code on behalf of others use the --author option, e.g. - When committing code on behalf of others use the `--author` option, e.g.
git commit -a --author "Joe Coder <joe@coder.org>" and --signoff. `git commit -a --author "Joe Coder <joe@coder.org>"` and `--signoff`.
Owen Taylor Owen Taylor
@ -70,3 +68,4 @@ Owen Taylor
Matthias Clasen Matthias Clasen
31 Mar 2009 31 Mar 2009