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]

Re: GCC Git hooks


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]