lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120804035702.GA2788@leaf>
Date:	Fri, 3 Aug 2012 20:57:03 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Alex Kelly <alex.page.kelly@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ian Campbell <Ian.Campbell@...rix.com>,
	Richard Weinberger <richard@....at>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts/get_maintainer.pl: Default to --no-rolestats
 when output not a terminal

On Fri, Aug 03, 2012 at 05:37:30PM -0700, Joe Perches wrote:
> On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> > On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > > scripts/get_maintainer.pl defaults to showing --rolestats, which
> > > > provides annotations explaining why each person or list might want to
> > > > know about a patch.  This works well for interactive use, but breaks
> > > > when used with git send-email's --to-cmd or --cc-cmd, resulting in
> > > > malformed email headers and mails sent to some but not all recipients.
> > > > 
> > > > To avoid the need to explicitly pass --no-rolestats for batch use,
> > > > enable --rolestats by default only when outputting to a terminal.
> > > 
> > > Hi Josh.
> > > 
> > > I think it's preferable to add --no-rolestats
> > > to the uses that need them.
> > 
> > Why?
> > 
> > > I have different scripts that I use for git send-email
> > > options --to-cmd and --cc-cmd
> > [...snip scripts...]
> > 
> > You've submitted enough patches that you've automated as much of the
> > process as you can; I don't think that makes the defaults less
> > error-prone.
> 
> I think the default use of the get_maintainer script is
> actually not scripted but interactive, where the user is
> just trying to figure out who the maintainer is.

I agree entirely; that's why I didn't change the default to always use
--no-rolestats, but rather to continue using --rolestats when
interactive and --no-rolestats when scripted.

> > As it stands now, the current default of --rolestats makes the obvious
> > command line of
> > git send-email --to-cmd='scripts/get_maintainer.pl' *.patch
> > send broken emails that go to some maintainers but not all.  I think it
> > makes sense to change the default so that the obvious usage becomes the
> > correct one.
> 
> There were some discussions awhile back in 2010 about the
> preferred defaults.
> 
> Perhaps you can read those discussions about why the default
> is the way it is.

I found commit 7e1863af1636b304a5f59aab6fb78d38e4079875, but that commit
does not serve the intended purpose.  Defaulting to --rolestats doesn't
make it "harder" to use get_maintainer.pl with git send-email, it just
makes it broken when used.  Meanwhile, the few discussions I see about
get_maintainer.pl just mention the problems caused by using --git, and
get_maintainer.pl has already improved to address those problems by not
using git commit signers for patches to files with active maintainers.

I don't see any value in making it intentionally harder to invoke
correctly while making it easier to invoke incorrectly.  Why not make it
actually work?

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ