Could we perhaps make some service, which would gather list of patches
sent to mailing list. And if Simon would not respond to it in any way,
it would make a list of sender, subject and name of patches in a summary.
If no response were say in a week, it might send a summary mail with a
list of such pending patches. Maybe supporting some keywords to mark a
reason, why it is not merged (yet).
It might be doable
Examples:
[merged] - merged as it is. In some cases this could be detected without
any message by watching git repo.
[modified] - merged by a different change. Solved the problem in a
different way.
[modify] - request to make a changes in patch, is waiting on the
contributor to do so
[refused] - stating such change won't be merged even with small
modifications, stop tracking that patch.
Altough it would be much easier if Simon would accept also pull requests
on any kind of git hosting service, which already provides a way to
create pull request, which can be commented on, merged or closed.
Services like github.com, gitlab or pagure already implements similar
workflows.
But above proposal would allow Simon just add those keywords into his
reply and otherwise do not change his way of processing incoming
patches. It would require to do some coding by us and hosting such
service somewhere.
Maybe even very simple reminder threads containing patches do not
contain any message for some time from Simon would help. Looking at
pipermail threads page, some hacking at HTML level in python might solve
that. Ideally with once a day generated page of links to messages
waiting for any comment, which could be checked any time.
On 3/16/23 22:51, Geert Stappers wrote:
Hi,
How can I help that patches get the attention that they deserve?
Groeten
Geert Stappers
On Wed, Mar 08, 2023 at 03:38:02PM +0000, Simon Kelley wrote:
On 07/03/2023 23:20, Clayton Craft wrote:
On Thu, 23 Feb 2023 21:40:10 -0800 Clayton Craft wrote:
On Fri, 10 Feb 2023 13:53:05 -0800 Clayton Craft wrote:
Any chance this could get merged? Being able to set filters at runtime is very
useful for multi-homed phones and other devices in cases where we need to
restrict DNS response answers based on IP protocol.
Please let me know if I need to make changes so that it is acceptable.
Is this patch something that could be accepted?
Apologies for ignoring you. Patch looks fine. Applied to git repo.
Cheers,
Simon.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
