On Mon, Feb 13, 2017 at 17:07:25 +0100, Max Kellermann wrote:
> But if something goes wrong, I want to know what went wrong, and I
> want that explanation, even if it's boring work. If I don't
> understand the problems, I'm losing control of the project, and if I
> lose control, random things start to happen.
>
> The patch was rejected twice not because I couldn't reproduce it, but
> because the two people who submitted it kept the build errors a
> secret. Just stating "it fails" is not something that allows anybody
> to comprehend the nature of the problem. One obvious idea is to
> publish the verbatim error message. But neither of the two did that.
I agree that explanations are nice, however, it might help to add the
policies for patches that are enforced to a `CONTRIBUTING.md` file
and/or to this page:
https://www.musicpd.org/doc/developer/submitting_patches.html
which is currently pretty spartan and doesn't mention any of the things
you (rightly) ask for. Some things I've noticed which should be
mentioned there:
- no iostream usage (due to "bloat", though a more detailed
explanation would be better since size vs. utility arguments are
present for the library);
- commit messages must explain what is going on and what they fix (for
bug fixes) or why they are necessary (for features) and stand on
their own without any explanation in the accompanying email; and
- send patches using `git send-email` (or some other patch-friendly
email setup, i.e., not the gmail web interface or Outlook).
I'm sure there are more.
Thanks for your continued maintenance,
--Ben
_______________________________________________
mpd-devel mailing list
mpd-devel@musicpd.org
http://mailman.blarg.de/listinfo/mpd-devel
