Re: Github action versioning
Hi all, As Apache Commons is a single Apache Project, we have one dev and one user ML. I think we should keep it that way, it helps Commons be Commons IMO. We also have one git commit ML. We could have an additional ML for robots which would only be used by services like github so any PR and Dependabot emails would go to the robots ML. The commit ML is a kind of robot so there some conceptual duplication IMO but we can all deal with it I am sure ;-) Thoughts? Gary On Sun, Aug 16, 2020, 09:48 John Patrick wrote: > 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 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 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 > >
Re: Github action versioning
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 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 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
Re: Github action versioning
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 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
Re: Github action versioning
I would not do that for Maven plugins in a POM, so I would not do that either for GitHub actions. Mailing list volume is a different topic. Gary On Sun, Aug 16, 2020, 05:55 Mark Thomas 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 > >
Re: Github action versioning
> On Aug 16, 2020, at 8:29 AM, Rob Tompkins wrote: > > > Sure. That’s why you’ve pulled me from a “no” to a non-blocking dissenting > opinion. I will go with community consensus at this point despite my opinion > (-0) (-; > > -Rob > >>> On Aug 16, 2020, at 8:25 AM, Xeno Amess wrote: >>> >> >> @Rob Tompkins >> Hi. >> Please consider: >> 1. Most people who subscribe commons-dev have no right to do any operations >> to dependabot prs. >> We can not help merge them, nor decline them & close them. Means reading >> such mails are a waste of time. >> 2. Most people who subscribe commons-dev actually do not really want to read >> such e-mails. >> 3. Dependabot mails usually have low value. Only maintainers should have >> some interest in watching them. And usually it will not break >> anything.(Just, usually, in most cases). >> 4. Dependabot mails are flooding. They are too many. >> 5. Dependabot mails cause argues about them (this happened several times >> this two weeks). >> >> Well my idea is we create a new mailing list named "commons-dev-auto" or >> "commons-dev-bot", who contains all the auto-email. >> >> > I want the emails as bots should be treated as people in some sense. >> >> But the reality is the bot is not people. Based on my readings about the theory of consciousness (See Annaka Harris’ book “Consciousness”), my feelings on the matter directly oppose yours here (agree to disagree). In fact I think that computers may actually have some self awareness. This may seem a tad loony and likely quite controversial. This is why I’m going to keep myself as non-blocking but dissenting as to keep my beliefs to myself and not impose upon the will of the community. :-) -Rob >> Besides, if there be such a people who make that much pr, will you promise >> review every of those prs, and do not complain about him be flooding? >> >> Rob Tompkins 于2020年8月16日周日 下午8:02写道： >>> >>> >>> > On Aug 16, 2020, at 5:59 AM, Xeno Amess wrote: >>> > >>> > I REALLY suggest we move all dependabot mails to another mailing list. >>> > please create one. >>> >>> Your point has pulled me from a -1 to a -0, where I want the emails as bots >>> should be treated as people in some sense. That said, I’m curious as to >>> what others think... >>> >>> Thoughts? >>> >>> -Rob >>> >>> > >>> > Mark Thomas 于 2020年8月16日周日 下午5:55写道： >>> > >>> >> 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 >>>
Re: Github action versioning
Sure. That’s why you’ve pulled me from a “no” to a non-blocking dissenting opinion. I will go with community consensus at this point despite my opinion (-0) (-; -Rob > On Aug 16, 2020, at 8:25 AM, Xeno Amess wrote: > > > @Rob Tompkins > Hi. > Please consider: > 1. Most people who subscribe commons-dev have no right to do any operations > to dependabot prs. > We can not help merge them, nor decline them & close them. Means reading such > mails are a waste of time. > 2. Most people who subscribe commons-dev actually do not really want to read > such e-mails. > 3. Dependabot mails usually have low value. Only maintainers should have some > interest in watching them. And usually it will not break anything.(Just, > usually, in most cases). > 4. Dependabot mails are flooding. They are too many. > 5. Dependabot mails cause argues about them (this happened several times this > two weeks). > > Well my idea is we create a new mailing list named "commons-dev-auto" or > "commons-dev-bot", who contains all the auto-email. > > > I want the emails as bots should be treated as people in some sense. > > But the reality is the bot is not people. > Besides, if there be such a people who make that much pr, will you promise > review every of those prs, and do not complain about him be flooding? > > Rob Tompkins 于2020年8月16日周日 下午8:02写道： >> >> >> > On Aug 16, 2020, at 5:59 AM, Xeno Amess wrote: >> > >> > I REALLY suggest we move all dependabot mails to another mailing list. >> > please create one. >> >> Your point has pulled me from a -1 to a -0, where I want the emails as bots >> should be treated as people in some sense. That said, I’m curious as to what >> others think... >> >> Thoughts? >> >> -Rob >> >> > >> > Mark Thomas 于 2020年8月16日周日 下午5:55写道： >> > >> >> 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 >>
Re: Github action versioning
@Rob Tompkins Hi. Please consider: 1. Most people who subscribe commons-dev have no right to do any operations to dependabot prs. We can not help merge them, nor decline them & close them. Means reading such mails are a waste of time. 2. Most people who subscribe commons-dev actually do not really want to read such e-mails. 3. Dependabot mails usually have low value. Only maintainers should have some interest in watching them. And usually it will not break anything.(Just, usually, in most cases). 4. Dependabot mails are flooding. They are too many. 5. Dependabot mails cause argues about them (this happened several times this two weeks). Well my idea is we create a new mailing list named "commons-dev-auto" or "commons-dev-bot", who contains all the auto-email. > I want the emails as bots should be treated as people in some sense. But the reality is the bot is not people. Besides, if there be such a people who make that much pr, will you promise review every of those prs, and do not complain about him be flooding? Rob Tompkins 于2020年8月16日周日 下午8:02写道： > > > > On Aug 16, 2020, at 5:59 AM, Xeno Amess wrote: > > > > I REALLY suggest we move all dependabot mails to another mailing list. > > please create one. > > Your point has pulled me from a -1 to a -0, where I want the emails as > bots should be treated as people in some sense. That said, I’m curious as > to what others think... > > Thoughts? > > -Rob > > > > > Mark Thomas 于 2020年8月16日周日 下午5:55写道： > > > >> 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 > >
Re: Github action versioning
> On Aug 16, 2020, at 5:59 AM, Xeno Amess wrote: > > I REALLY suggest we move all dependabot mails to another mailing list. > please create one. Your point has pulled me from a -1 to a -0, where I want the emails as bots should be treated as people in some sense. That said, I’m curious as to what others think... Thoughts? -Rob > > Mark Thomas 于 2020年8月16日周日 下午5:55写道： > >> 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
Re: Github action versioning
I REALLY suggest we move all dependabot mails to another mailing list. please create one. Mark Thomas 于 2020年8月16日周日 下午5:55写道： > 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 > >
Github action versioning
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
