OK, good news, I think I'm near being done! > Next on my list (in random order): > > - Provide a way to call the script which sends updates to bugzilla > > - Add a post-receive hook which we would call at the end > of our post-receive hook. This hook would then allow us > to the irker hook, for IRC notification. > > - Add an option to include a URL of the commit in the emails. > > - Merge commit control. All the above have been done :) > - Verify compatibility of the new hooks with the git version > installed on sourceware.org. This is where thing didn't go as well as I had hoped. I found that working with the versions of Python and git installed on sourceware would be too hard. So I sent an email to overseers to discuss solution about using newer versions. I don't think it'll take very long to resolve. > Once that's done, I think all features provided by the current hooks > will also be available in the new hooks, so we'll be able to start > working on the integration. I *think* I have everything covered if we use the config shown below (full doc: https://sourceware.org/gdb/wiki/proposed/git-hooks/UsersGuide). It handles: - dynamic computation of the email list (by attached email_to.py script). - rejection of merge commits on branch master and all GDB release branches. - filing of commits in bugzilla. - irker notification |[hooks] | from-domain = sourceware.org | mailinglist = /git/binutils-gdb.git/hooks-bin/email_to.py | | # We do not want to force a maximum line length in commit | # revision logs, as they get in the way of copy-pasting | # debugging session, error messages, logs, etc. | max-rh-line-length = 0 | | # Reject merge commits on a certain number of branches: | # - on master: We request that people rebase their changes | # before pushing instead (merge commits tend to confuse | # git newcommers). | # - on GDB release branches: There is a high risk that a merge | # commit is a merge from master into the branch, which would | # bring a lot more than what the user probably meant to push. | # Request that the user cherry-pick his changes. | reject-merge-commits = refs/heads/master, refs/heads/gdb-.* | | # The style checker, applied to the contents of each file being | # modified. | style-checker = /git/binutils-gdb.git/hooks-bin/style_checker | | # The URL where we can inspect the commit, inserted in the commit | # notification email, and also copy sent to the file-commit-cmd. | commit-url = "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=%(rev)s" | | # Do not send emails for the following branches (unofficial | # third-party branches). | # FIXME: It would be nice to move the "hjl" branches to /user/. | no-emails = /refs/heads/hjl/.*, /refs/heads/user/.* | | # Send a copy to bugzilla if a commit has a PR number in it. | file-commit-cmd = /sourceware/infra/bin/email-to-bugzilla -G "gdb binutils" | # The script that calls the irker (IRC notification of new | # commits). | post-receive-hook = /git/binutils-gdb.git/hooks-bin/post-receive Note that this also introduces a "style checker", which is a script called to check the contents of each and every file being modfied by a given commit. At the moment, the script does nothing, but we could imagine checking things like copyright headers, style violations; and this checking can very well be dependent on the type of file. But that's a project on its own for which I won't have time. If someone implements something, I'll integrate it! Timeline: ========= If people are happy with the above, when do we want to transition. I feel the best time for me would be during the Xmas break. How do people feel about me doing the transition sometime after Monday Dec 29th? Reminder: hooks sources at https://gitorious.org/githooks -- Joel