This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello everyone, On Sat, Sep 14, 2019 at 04:53:17PM -0400, Jason Merrill wrote: > At Cauldron this weekend Joel offered to adjust his git hooks > (https://github.com/brobecke/git-hooks), which are already used by gdb > and glibc, to meet GCC's needs. Separately, Joseph volunteered to > deal with converting the gcc-www repository to git and dealing with > those hooks. > > I expect that Joel's hooks should work fine for gcc-www with minimal > changes, but that the main GCC repository will need more work for > bugzilla integration. > > The GCC SVN hooks initially look like pretty vanilla SVN hooks using > svnmailer (http://opensource.perlig.de/svnmailer/); the customized > part of the svnmailer.conf is just > > [libstdcxx] > for_paths = .*(libstdc..-v3)/.* > to_addr = libstdc++-cvs@gcc.gnu.org > > [java] > for_paths = .*(boehm-gc|fastjar|gcjx|gcc/java|libffi|libjava|zlib)/.* > to_addr = java-cvs@gcc.gnu.org > > [gccdefault] > to_addr = gcc-cvs@gcc.gnu.org > bugzilla_to_addr = gcc-bugzilla@gcc.gnu.org > > Pretty short...but the last line relies on Daniel's custom > bugzilla/svnmailer integration (attached below), and it looks like > Joel's hooks don't have anything comparable. Any thoughts about > adjusting Daniel's bugzilla.py vs. pulling in something like > http://www.theoldmonk.net/gitzilla/ ? Looking at the configuration file, I believe the git-hooks should have most, if not all, of the features that would be needed for the GCC repository. In particular, there is already a way to relay commits to third-party tools via calling of a script; GDB uses that to interface with their Bugzilla database. But before I say more I should point to the documentation which, for historical reasons, is available on the GDB wiki rather than the git-hooks GitHub repository. I will fix that, but in the meantime: https://sourceware.org/gdb/wiki/GitHooksUsersGuide I'm attaching a file called project.config, which shows the current configuration for the GDB repository, as it is might be a good starting point for GCC's configuration. Of interest: * We can see that "hooks.mailinglist" is pointing to a script. The purpose of that script is to determine, based on which files changed, which mailinglists should the commit email be sent to. * There is a hooks.style_checker line. Currently, GDB points to a script which does nothing. If GCC has some scripts they want to be run to validate the contents of a file, this is where this can be done. There is no mechanism, really, to say "don't run the style_checker", but it's easy to just pass a null style_checker as done by GDB. * For bugzilla integration, GDB uses the hooks.file-commit-cmd file. I'm attaching the email-to-bugzilla script, although I don't know how useful it will be for GCC. It predates the git-hooks and I just re-used it as is when we switched over to the git-hooks. Given that, it seems like the git-hooks might be ready to support all the needs of the GCC repository? We would need to: - write a script that determines the list of recipients based on the list of files being changed; that should be a trivial adaptation of the script used on the GDB side; - Adapt the script filing the commit with bugzilla - create a refs/meta/config "branch", and add the project.config file with the git-hooks configuration. I can definitely help with the configuration setup phase in whatever capacity you'd like. I would recommend people take a look at the list of options currently available to see what kind of initial configuration we might want to start with. -- Joel
Attachment:
project.config
Description: Text document
#! /usr/bin/env python import sys ML_MAP = {'bfd': 'bfd-cvs@sourceware.org', 'gdb': 'gdb-cvs@sourceware.org', } OWNER_MAP = ( # BFD file... ('bfd/', 'bfd'), ('binutils/', 'bfd'), ('opcode/', 'bfd'), ('cpu/', 'bfd'), ('elfcpp/', 'bfd'), ('gas/', 'bfd'), ('gold/', 'bfd'), ('gprof/', 'bfd'), ('include/', 'bfd'), ('ld/', 'bfd'), ('opcodes/', 'bfd'), # GDB files... ('gdb/', 'gdb'), ('readline/', 'gdb'), ('sim/', 'gdb'), ) EVERYONE = set(ML_MAP[ml_key] for ml_key in ML_MAP) def ml_from_filename(filename): for (path, ml_key) in OWNER_MAP: if filename.startswith(path): return ML_MAP[ml_key] # Not found in map, it is a common file. return EVERYONE result = set() for filename in sys.stdin: ml = ml_from_filename(filename) if isinstance(ml, basestring): result.add(ml) else: result.update(ml) if len(result) >= len(EVERYONE): # We have iterated over enough entries to know already # that we have selected all possible recipients. So # stop now. break if not result: # No files given, return EVERYONE result = EVERYONE print '\n'.join(sorted(result))
Attachment:
email-to-bugzilla
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |