My task this weekend has been tracking down mismatches between trunk and branch 3.4 to make sure that anything that has been committed to trunk and is or should be targeted for the 3.4.2 release has been committed to the branch.
In doing that I'm encountering a number of commits to trunk that do not refer back to a Bugzilla issue. Usually it is a simple and obvious patch for an issue that clearly ought to be done, and probably didn't seem worth the extra steps of creating an issue in Bugzilla for it. Maybe some of them were a result of the committer not including the bug number in the commit message - I would not be able to tell if that's the case without a search in Bugzilla in which I guess the keywords to look for. I propose that we make a practice of 1) Create a Bugzilla issue for anything we commit to source files or to any other files that are part of the build process; 2) Include the text "bug NNNN" somewhere in the commit message. The benefits of doing this include 1) Makes it easier to track what has to be ported from trunk to branch before a release; 2) Makes it possible to look up the reasons and discussions related to a commit, and to find other commits that are related to the same issue even when at the time of the first commit it was not anticipated that there would be anything more to be committed. We already have in our guidelines to include "bug NNNN" in the commit message https://wiki.apache.org/spamassassin/UsingBugzilla#Committing_Fixes_For_Bugs I would like to see if there is consensus on adding to our guidelines that we always create a Bugzilla issue for something that will be committed into our source or related files. It also seems like a good idea to create a CommitterGuidelines page on the wiki. I had some difficulty finding the guideline for svn commit messages where it is hiding under UsingBugzilla. Comments, votes? Sidney
