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