Update README.commits
Updated info to reflect current gtk2-ng project
This commit is contained in:
parent
7c83c8ec9c
commit
d128c9efde
1 changed files with 19 additions and 56 deletions
|
|
@ -1,72 +1,35 @@
|
|||
GTK+ is part of the GNOME git repository. At the current time, any
|
||||
person with write access to the GNOME repository, can make changes to
|
||||
GTK+. This is a good thing, in that it encourages many people to work
|
||||
on GTK+, and progress can be made quickly. However, GTK+ is a fairly
|
||||
large and complicated package that many other things depend on, so to
|
||||
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
|
||||
people committing to GTK+ to follow a few rules:
|
||||
The gtk2-ng project is part of Daemonratte's git repository. At the current
|
||||
time, only the project owner and collaborators are allowed to make commits,
|
||||
gtk2-ng is a fairly large and complicated package that many other things
|
||||
depend on, so to avoid unnecessary breakage, but to take advantage of the
|
||||
knowledge about GTK that has been built up over the years, we'd like to ask
|
||||
people to feel free to submit pull requests after modding and testing. It
|
||||
will all get reviewed though sometimes that may take some time!
|
||||
|
||||
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
|
||||
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,
|
||||
somebody may know a better way to do things.
|
||||
|
||||
If you are making changes to GTK+, you should be subscribed
|
||||
to gtk-devel-list@gnome.org. (Subscription address:
|
||||
gtk-devel-list-request@gnome.org.) This is a good place to ask
|
||||
about intended changes.
|
||||
|
||||
#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,
|
||||
however, email to gtk-devel-list is the most certain and preferred
|
||||
method.
|
||||
|
||||
1) Ask _first_.
|
||||
|
||||
2) With git, we no longer maintain a ChangeLog file, but you are expected
|
||||
to produce a meaningful commit message. Changes without a sufficient
|
||||
commit message will be reverted. See below for the expected format
|
||||
of commit messages.
|
||||
If you would like to submit pull requests, you will need to have an account
|
||||
at: https://git.devuan.org
|
||||
It's also a good idea to sign up at the devuanusers.com forum and join the
|
||||
discussion here: https://devuanusers.com/forum-gtk2-revival-project--12
|
||||
|
||||
Notes:
|
||||
|
||||
* When developing larger features or complicated bug fixes, it is
|
||||
advisable to work in a branch in your own cloned GTK+ repository.
|
||||
advisable to work in a branch in your own cloned gtk2-ng repository.
|
||||
You may even consider making your repository publically available
|
||||
so that others can easily test and review your changes.
|
||||
|
||||
* The expected format for git commit messages is as follows:
|
||||
|
||||
=== begin example commit ===
|
||||
Short explanation of the commit
|
||||
Title: Short explanation of the commit, i.e "Update foo.c"
|
||||
|
||||
Optional extended description: Longer explanation about what's changed,
|
||||
whether any external or private interfaces changed, what bugs were fixed
|
||||
(with bug tracker reference if applicable) and so on. Be concise but complete,
|
||||
i.e. "Added new spin-buttons, deleted some trailing whitespace, fixed bug #8"
|
||||
|
||||
~greenjeans June 2026
|
||||
|
||||
Longer explanation explaining exactly what's changed, whether any
|
||||
external or private interfaces changed, what bugs were fixed (with bug
|
||||
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
|
||||
the commit and terminate by two newlines (it will work without the
|
||||
second newline, but that is not nice for the interfaces).
|
||||
|
||||
- First line (the brief description) must only be one sentence and
|
||||
should start with a capital letter unless it starts with a lowercase
|
||||
symbol or identifier. Don't use a trailing period either. Don't exceed
|
||||
72 characters.
|
||||
|
||||
- The main description (the body) is normal prose and should use normal
|
||||
punctuation and capital letters where appropriate. Normally, for patches
|
||||
sent to a mailing list it's copied from there.
|
||||
|
||||
- When committing code on behalf of others use the --author option, e.g.
|
||||
git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
|
||||
|
||||
|
||||
Owen Taylor
|
||||
13 Aug 1998
|
||||
17 Apr 2001
|
||||
|
||||
Matthias Clasen
|
||||
31 Mar 2009
|
||||
|
|
|
|||
Loading…
Reference in a new issue