public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: scripts/get_maintainer.pl misses maintainers sometimes
Date: Thu, 13 Jul 2017 15:22:34 -0700	[thread overview]
Message-ID: <1499984554.4457.64.camel@perches.com> (raw)
In-Reply-To: <1499878121.4457.33.camel@perches.com>

On Wed, 2017-07-12 at 09:48 -0700, Joe Perches wrote:
> On Wed, 2017-07-12 at 18:36 +0200, Maarten Lankhorst wrote:
> > Hello Joe Perches,
> > 
> > I created a script for drm's maintainer-tools that pipes the output of get_maintainer.pl
> > to add the appropriate cc's to the commit message. It also ignores duplicates, so running
> > the script twice on the same commit doesn't add everyone twice.
> > 
> > When testing, I found out that sometimes maintainers were added on the second patch, and
> > that made me notice a bug in get_maintainer.pl.
> > 
> > On the below patch, I get up to 39 maintainers from get_maintainer.pl, but the actual amount 
> > differs randomly on each invocation:
> > 
> > ~/linux$ git show | scripts/get_maintainer.pl | wc -l
> > 39
> > ~/linux$ git show | scripts/get_maintainer.pl | wc -l
> > 37
> > ~/linux$ git show | scripts/get_maintainer.pl | wc -l
> > 38
> > 
> > Any idea why this happens?
> 
> If you add --nogit --nogit-fallback to the command line
> the output is consistent.
> 
> So it seems it comes down to that what git log outputs
> for the same command varies.
> 
> I'll track it down further later.

It doesn't actually seem like a bug so much as
unreproducibility of the script output.

It seems to come down to this line in the script in
subroutine vcs_assign:

    foreach my $line (sort {$hash{$b} <=> $hash{$a}} keys %hash) {

where there is a hash of sorted commit signers and this is
selecting the ones with the most signatures.

When there are multiple signers with the same number of commits,
perl is picking a random entry.

I think it's not particularly important to be reproducible as
the MAINTAINERS entries should be prioritized and the git
commit signers should only be considered when there is no
listed maintainer.

If you have a bright idea as to how perl should order the
entries in the hash for reproducibility, let me know.

cheers, Joe

      reply	other threads:[~2017-07-13 22:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12 16:36 scripts/get_maintainer.pl misses maintainers sometimes Maarten Lankhorst
2017-07-12 16:48 ` Joe Perches
2017-07-13 22:22   ` Joe Perches [this message]

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=1499984554.4457.64.camel@perches.com \
    --to=joe@perches.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    /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