My mail server doesn’t offer sophisticated enough filtering to properly filter out that sort of thing. For example, while I can set up a filter around Dependabot itself, that doesn’t handle all the automated emails in response to that such as a committer merging the update. And that’s besides the GitHub notification emails having such terrible subjects that they’re hardly useful to read without opening the email itself.
Now that we have the tools to do it, I think we should. If there are no objections, I’ll look into configuring this sometime soon (though still fairly busy at work until the end of the month). > On Feb 15, 2023, at 10:20 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > I was able to set up filtering at my mail server to route all the automated > stuff to other folders. However, The Jira stuff still gets mixed in with > GitHub stuff. But the more we can do to separate the noise the better. > > Ralph > >> On Feb 15, 2023, at 1:06 PM, Matt Sicker <boa...@gmail.com> wrote: >> >> Seems as though the .asf.yaml file now supports not only redirecting the bot >> emails to another list, but we can reconfigure the subjects generated in the >> GitHub notifications which are otherwise nearly useless to skim over. >> >> I still can’t keep up with this project very well anymore because of the >> Dependabot flooding. >> — >> Matt Sicker >> >>> On Feb 6, 2023, at 11:35, Matt Sicker <m...@musigma.org> wrote: >>> >>> I don’t want to get rid of the bot; it’s very useful. I just don’t want its >>> notifications in my inbox, especially since they’re nearly impossible to >>> filter without false positives (e.g., I can filter email from the bot >>> itself, but then I still get emails from anyone here who interacts with the >>> bot when dealing with its PRs which ends up flooding the notifications >>> list, too). It’s simple enough to view the pull requests tab on GitHub once >>> in a while to handle dependency updates (especially before beginning the >>> release process). The rest of the notification activity we get is low >>> volume enough that I should be able to follow it on a daily basis (and is >>> how I typically notice new issues filed, new pull requests, etc). >>> >>>> On Feb 6, 2023, at 2:50 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>> >>>> I wouldn't aim for an exhaustive list. Your compilation is better than what >>>> we have right now, which is nothing. If we encounter something new, we can >>>> extend this list. >>>> >>>> I think your changes could very well live in the official repository. I >>>> don't think the disruption is big enough to warrant work in a fork. But you >>>> can decide this yourself. >>>> >>>> On Mon, Feb 6, 2023 at 9:37 AM Piotr P. Karwasz <piotr.karw...@gmail.com> >>>> wrote: >>>> >>>>> Hi Volkan, >>>>> >>>>> On Mon, 6 Feb 2023 at 08:55, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>>>> >>>>>> You can configure dependabot to ignore certain major versions or update >>>>>> types >>>>>> < >>>>> https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore >>>>>> >>>>>> : >>>>>> >>>>>> ... >>>>>> >>>>>> Doesn't this help you with your concern? >>>>> >>>>> That is exactly what I have done: >>>>> >>>>> https://github.com/ppkarwasz/logging-log4j2/blob/2.x/.github/dependabot.yml >>>>> >>>>> My main concern is: >>>>> >>>>> * is this list (mostly) complete? >>>>> * for some dependencies (e.g. `slf4j-api`) we use multiple (1.7.25, >>>>> latest 1.7.x and latest 2.x) versions depending on the module. >>>>> >>>>> I'll let Dependabot run for a couple of weeks on my fork, before >>>>> submitting a PR to the main repo. >>>>> >>>>> Piotr >>>>> >>> >> >
