Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org, binutils@sourceware.org
Subject: Re: RFC: using AdaCore's git hooks for binutils-gdb.git ...
Date: Sun, 21 Dec 2014 22:46:00 -0000	[thread overview]
Message-ID: <20141221224607.GN12884@adacore.com> (raw)
In-Reply-To: <20141214204731.GA15244@adacore.com>

[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]

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

[-- Attachment #2: email_to.py --]
[-- Type: text/x-python, Size: 1243 bytes --]

#! /usr/bin/env python
import sys

ML_MAP = {'bfd': 'bfd-cvs@example.com',
          'gdb': 'gdb-cvs@example.com',

          }

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))

  reply	other threads:[~2014-12-21 22:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28 13:58 Joel Brobecker
2014-11-28 14:08 ` H.J. Lu
2014-11-28 14:27   ` Joel Brobecker
2014-11-28 14:42     ` Joel Brobecker
2014-11-28 18:06   ` Joseph Myers
2014-11-28 20:50 ` Sergio Durigan Junior
2014-11-29  2:53   ` Joel Brobecker
2014-12-01 11:34 ` Pedro Alves
2014-12-07 14:21 ` Joel Brobecker
2014-12-08  6:05   ` Sergio Durigan Junior
2014-12-13 16:51   ` Joel Brobecker
2014-12-14 20:47     ` Joel Brobecker
2014-12-21 22:46       ` Joel Brobecker [this message]
2015-01-05  4:13         ` Joel Brobecker
2015-01-10  6:59           ` ANNOUNCEMENT: we have now switched to new git hooks (was: "Re: RFC: using AdaCore's git hooks for binutils-gdb.git ...") Joel Brobecker
2015-01-11 16:21             ` H.J. Lu
2015-01-12  4:08               ` Joel Brobecker
2015-01-12  4:16                 ` Joel Brobecker
2015-01-12 18:03                   ` Cary Coutant
2015-01-12  4:58               ` Joel Brobecker
2015-01-12  5:05                 ` H.J. Lu
2015-01-12  6:56                   ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141221224607.GN12884@adacore.com \
    --to=brobecker@adacore.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox