linux-kernel - Re: Git pull ack emails..

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181026211504.GG27137@sirena.org.uk>
Date:   Fri, 26 Oct 2018 22:15:04 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Rob Herring <rob.herring@...aro.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        kirill@...temov.name, Linus Walleij <linus.walleij@...aro.org>,
        boris.brezillon@...tlin.com,
        Catalin Marinas <catalin.marinas@....com>,
        Christoph Hellwig <hch@....de>,
        Guenter Roeck <linux@...ck-us.net>, jacek.anaszewski@...il.com,
        axboe@...nel.dk, Ulf Hansson <ulf.hansson@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Git pull ack emails..

On Fri, Oct 26, 2018 at 12:36:14PM -0500, Rob Herring wrote:
> On Thu, Oct 25, 2018 at 9:14 AM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:

> > Are there other situations where you might want to track something
> > _outside_ of a pull request? Maybe. I can't really think of a lot of
> > them, though. Patches etc don't have commit ID's to track, but it

patchwork gives them IDs and lets you do lookups using them, that's what
I'm doing.  You can get the ID from a git commit by piping the output of
git show into parser.py from the patchwork source, it works a lot of the
time but things like editing the commit message will break it (this is a
theme with my scripting around the mail stuff...).

> submissions. For example, with Greg and Mark B you can expect an
> automated replies. Mark's reply gets threaded with the original, but
> Greg's do not. For networking, you may or may not get a manual reply,

Mine *mostly* gets threaded, it's relying on being able to talk to
patchwork to figure out the message ID at the minute so if the patchwork
lookup fails for whatever reason it'll just use on what's in the commit
for the CC list and not thread.  That isn't ideal, especially when I'm
travelling and my network connection isn't the best, I keep meaning to
try to figure out a better way which would probably be based on git
notes as discussed earlier.

> maintainers apply. I've somewhat solved it for myself by automating
> checking linux-next, but maybe automated email replies to patches
> being in linux-next would be nice. While that's not immediate, it

Yeah, I do that as well (I have an outbound patch queue I rebase against
-next, this also tells me if stuff starts conflicting with other work).
I can see the automated e-mails be useful but it might be tricky for a
bot that's only looking at git to figure out which people and lists to
CC to ensure visibility unless we do the annotation thing, it's not just
the patch submitters that want visibility - I did the patchwork stuff
due to user demand for that with some help from Brian Norris.

> BTW, patchwork tracks pull requests too, so maybe there's a common solution.

Ooh, interesting...

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)