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. 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
