I wonder if openjdk has considered all the auto generated traffic that might be triggered from github. As for JDK 16 they are moving from Mercurial to Git, and moving from internal hosting to Github. I guess we will know shortly as ramp down for JDK 16 will start something in december.
Having seen renovate (similar to dependabot) enabled for cucumber in july, and the spike of ~50 pr initially, which each having an email about code coverage, then another when approved and merged, then each time rebased, another email and another code coverage email, until the final merge email. It was a downpour of emails. I expect commons will see similar spikes after a release of a project, as so many projects on the same mailing lists, and when a release train starts it cascades automatically, but it's better than someone having to manually perform those tasks. The question I guess is how do those with commit/approve privileges want to receive notifications about PR's, comments and merges. With dependabot adding automation, is it time to split out those github event triggered emails to maybe commons-github or commons-lang-github. If the people with the power believe they are being overloads with an increase of traffic, it would give them the opportunity to only receive notifications for projects they want to maintain. Splitting dependabot from user triggered events, if you're wanting to avoid or mute dependabot emails, you might as well simply disable dependabot. Using gmail, it does allow simple filtering and displaying those threads, I wouldn't want to receive github event emails using an email client that doesn't automatically group email threads. That reminds me, should I be top commenting or bottom commenting or inline commenting for commons emails, as gmail defaults to top. John On Sun, 16 Aug 2020 at 14:10, Mark Thomas <ma...@apache.org> wrote: > > On 16/08/2020 13:58, Gary Gregory wrote: > > I would not do that for Maven plugins in a POM, so I would not do that > > either for GitHub actions. > > Fair enough. It looked to me as if these updates were being approved > largely automatically hence the suggestion to skip that and just let the > upgrades happen. The option is there for components that want to use it. > > > Mailing list volume is a different topic. > > Indeed. > > Mark > > > > > Gary > > > > On Sun, Aug 16, 2020, 05:55 Mark Thomas <ma...@apache.org> wrote: > > > >> Hi, > >> > >> I am seeing an awful lot of list traffic generated for patch updates to > >> github actions e.g. updating from v1.4.0 to v1.4.1 > >> > >> Having read [1], my understanding is that we can specify v1 and that > >> will always point to the latest 1.x.x release. > >> > >> Would it not be better to specify v1 for these actions as that way: > >> - we use the latest version automatically (until 2.x.x is released) > >> - we avoid all the noise on the mailing list > >> > >> Mark > >> > >> > >> > >> [1] https://docs.github.com/en/actions/creating-actions/about-actions > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
