It also makes it easier to contribute, as you don't end up wondering
about a weird requirement and ensuring that your ChangeLog diff is
unstaged when committing :)
On 29/10/2017 14:46, Ivan Vučica wrote:
http://www.gnustep.org/developers/bugs.html
Quoting:
"""
Sending fixes
Actually fixing problems is even more appreciated than sending in bug
reports. To do this, first fix the bug and make sure it works. Then
send in a diff file containing the differences between the old version
of the file(s) you changed and the new version. Use the diff (diff -u)
program to do this. Then add a ChangeLog entry in front of this and
send the whole thing to bug-gnus...@gnu.org <mailto:bug-gnus...@gnu.org>.
If you use emacs, it is easy to add a ChangeLog entry. Just edit the
file you changed, and move the cursor to the function or method you
changed, then type
M-x add-change-log-entry
and emacs automatically formats an entry in the ChangeLog file with
the information on the file and function you changed. You just need to
add a comment about what was fixed. Note: Don't send a diff of the
ChangeLog file, just send a copy of your ChangeLog entry normally.
Here is an example ChangeLog:
<snip>
"""
(1) I think I am subscribed to bug-gnustep@. I don't recall receiving
any patches recently that way. I think it's still okay to suggest this
mailing list, as long as we're aware of it.
(2) This is the actual reason why I'm sending this email: """Note:
Don't send a diff of the ChangeLog file""". This has been interpreted
by a contributor as "Don't include ChangeLog in your commits", which
is technically accurate (as commits are not much more than patches),
but creates extra burden on the maintainer.
I'd suggest removing this sentence; whether the patch is submitted
over email or through some contribution management system (e.g. one
that allows pull requests), I think it's better to request
contributors to update ChangeLog entries than not, because then the
maintainer needs to come up with a change.
This is the practice which we had for Google Summer of Code.
This may have made some vague sense in the world of Subversion or CVS
or patch-via-email, but right now it's just creating overhead.
Can we strike it out, or at the very least say "This only applies when
you're contributing via a mailing list, and not when you are
contributing otherwise"?
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev