https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218024
Unbreak by fixing MASTER_SITES
Pass maintainership to submitter
Add proper WWW URL
Differential D10118
Update sysutils/rsyncbackup to 1.1 krion on Mar 23 2017, 11:20 AM. Authored by Tags None Referenced Files
Subscribers
Details
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218024 Unbreak by fixing MASTER_SITES
Diff Detail
Event TimelineComment Actions You are not "unbreak by changing the MASTER_SITE", you are updating to a new version, which happens to have moved some place else, so, that bit is not needed. Also, "Add proper WWW URL" is wrong, it would be more of a "Update WWW to follow new upstream" but it is not needed at all so you can remove it. Remember, the commit message is the place you say why you are doing the thing that are done in the commit. It is not the place where you explain in detail all the things you changed, those things can be seen looking at the diff.
Comment Actions Yes and that is the struggling point where some individuals would whine about not getting enough information from commit message, I have tons of examples about it. Some would like to get every bit explained and someone is satisfied by brief description. Both are right from their point of view, it just the matter of taste. Comment Actions If you are referring to what @danfe told you, he was right for some points, what a commit message need to have is the why in the case of rP436712, the commit message should have contained "previous maintainer has 3 timeouts, giving maintainership to submitter". A commit need to be able to stand alone, the diff says what you did, the commit message says why. So that nobody has to go and look at other sources of information to figure out what happened. Ports committers are notoriously bad at writing commit messages, but it is not because everyone is doing it badly that you can do it badly too. If nobody shows how it should be done, nobody will ever get better. Comment Actions Thank you for words of support Mathieu, I appreciate it. Kirill, I'm sorry, but this is not a matter of personal taste. What might seem like an obvious thing to you (or submitter of a patch) might be totally confusing for someone who comes by the port to do some work on it (e.g. handle next PR) several months or years later. Documenting changes thoroughly helps to preserve the knowledge and context between past, present, and future maintainers and committers. People come and go, and might not be around next time ready to answer the questions like "why/what for did you do this thing this particular way".
|