From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: workflows@vger.kernel.org
Subject: Re: Monitoring the status of your own patches on patchwork?
Date: Mon, 13 Dec 2021 19:39:27 +0100 [thread overview]
Message-ID: <87zgp4z6w0.fsf@toke.dk> (raw)
In-Reply-To: <20211213080625.7febffc2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Jakub Kicinski <kuba@kernel.org> writes:
> On Mon, 13 Dec 2021 16:48:37 +0100 Toke Høiland-Jørgensen wrote:
>> > Status notification when checks are failing? Hopefully not, we don't
>> > want people posting patches just to get them tested...
>>
>> Well no, but sometimes a patch will have failures despite the best
>> efforts of the submitter (otherwise what's the point of the checks?).
>> Right now the only way for me to discover that there's an issue is to go
>> look at the patchwork web interface, and I wanted something that better
>> suits my workflow (i.e., that's not in a web browser).
>
> I think that the maintainer should notify the submitter about
> the reason the patch state was changed (with the exception of
> patches for a different tree, maybe). I know Kees has been
> trying to add more meaningful states to patchwork but I can
> never guess the meaning of those either :S So no automated
> state checker can replace the maintainer's reply.
Well, sometimes the maintainers forget to reply entirely :)
And yeah, I do realise that no bot is going to be able to tell me
exactly what the current status is, I just want a tool to help me
manually keep track...
>> I wasn't asking for patchwork to send out automatic notifications
>> (yikes!), I just wanted to know if anyone else had done something
>> similar before I go play around with the patchwork API myself... :)
>
> Despite the promise of "best effort" I fear such automation.
> It's pretty common in (let's call them) modern workflows to
> submit PRs / post changes just to get them tested by a CI.
> We don't want to give people the impression that the mailing
> list can serve this purpose.
People could already do that, though, they just have to look at the
patchwork site. And I really don't think it's that convenient of an
interface that this is a real risk. But don't worry, I'm not planning to
publish this as a generally-available service :)
-Toke
next prev parent reply other threads:[~2021-12-13 18:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-11 19:06 Monitoring the status of your own patches on patchwork? Toke Høiland-Jørgensen
2021-12-13 15:08 ` Jakub Kicinski
2021-12-13 15:48 ` Toke Høiland-Jørgensen
2021-12-13 16:06 ` Jakub Kicinski
2021-12-13 18:39 ` Toke Høiland-Jørgensen [this message]
2021-12-13 22:56 ` Kees Cook
2021-12-13 18:37 ` Simon Glass
2021-12-13 21:43 ` Toke Høiland-Jørgensen
2021-12-13 23:51 ` Simon Glass
2021-12-14 2:12 ` Randy Dunlap
2021-12-14 16:31 ` Simon Glass
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=87zgp4z6w0.fsf@toke.dk \
--to=toke@redhat.com \
--cc=kuba@kernel.org \
--cc=workflows@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.