+1 to Jan's idea :D I think it's better to split the mailing list. But I have a little opinion about the name. Which one is better, the singular(build-issue) or the plural(builds-issues)? Personally, "build-issue" looks better because names of the our mailing list are used as a singular. (not jave-users but java-user)
What do you think about this? 2019년 8월 8일 (목) 오후 9:42, Jan Høydahl <[email protected]>님이 작성: > I'll let this email topic run over the weekend to attract more eyeballs. > Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if > others also seem in favour of this idea then I'll start working on it next > week. To sum up what I believe to be the current consensus: > > A new issues@ list (announce only) for JIRA and Github notifications > A new build@ list (announce only) for Jenkins notifications > > Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is > still an open question. To help decide, here's the expected volume for > those (from reporter.apache.org: > 357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past > quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, > past quarter > …which sums up to about 300/month or 10/day. > An alternative to this could be some script that runs once a day and emits > ONE email per day with a digest with links to new/closed JIRAs and PRs last > 24h. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 8. aug. 2019 kl. 14:15 skrev Erick Erickson <[email protected]>: > > +1 to Jan’s idea of the bot-originated lists be announce only….. > > Personally I’ve been able to make some sense out of the messages by > > 1> switching to the mac mail client (not an option for others, I know). It > threads pretty well and for those topics where there are 10 replies I only > have to glance at one to see if I’m interested enough to pursue. > > 2> I have a _lot_ of filters set up. > > I have to admit that one of the motivations for moving to the mail program > on the mac was because gmail’s filters are such a disaster. Or I just > totally missed how to configure them. For instance, changing the order of > execution was impossible, so when I wanted to make a new filter execute > first I had to redefine the entire list….. > > On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch <[email protected]> > wrote: > > I apply the following (gmail) rules, just in case it helps somebody. > With this combination, I am able to track human conversations > reasonably well. > > Human conversation: > Matches: from:([email protected]) subject:(-[jira]) list:< > dev.lucene.apache.org> > Do this: Skip Inbox, Apply label "ML/Lucene-dev" > > All JIRA issues, regardless of other filters > Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org" > Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam > > New JIRA issues (that I check to see if I want to track/comment before > I remove the label) > Matches: subject:("[Created]") list:(<dev.lucene.apache.org>) > Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never > send it to Spam > > Updates on JIRA issues from me (I already know them) > Matches: from:(Alexandre Rafalovitch (JIRA) <[email protected]>) > Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras" > > All JIRA issues I am involved in or marked to track > Matches: from:([email protected]) to:([email protected]) > Do this: Skip Inbox, Apply label "Solr-Jiras" > > Delete JENKINS stuff, as I am currently not contributing > Matches: subject:([JENKINS]) list:(<dev.lucene.apache.org>) > Do this: Delete it > > Git emails that I am not really tracking right now, but do keep > Matches: from:([email protected]) list:(<dev.lucene.apache.org>) > Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox", > Never send it to Spam > > Moderation emails I help with > Matches: subject:(MODERATE for [email protected]) > Do this: Skip Inbox, Apply label "Solr-Moderate" > > Matches: list:"<solr-user.lucene.apache.org>" > Do this: Skip Inbox, Apply label "ML/SolrUsers" > > Regards, > Alex. > > On Wed, 7 Aug 2019 at 07:54, David Smiley <[email protected]> > wrote: > > > It's a problem. I am mentoring a colleague who is stressed with the > prospect of keeping up with our community because of the volume of email, > and so it's a serious barrier to community involvement. I too have email > filters to help me, and it took some time to work out a system. We could > share our filter descriptions for this with workflow? I'm sure I could > learn from you all on your approaches, and new collaborators would > appreciate this advise. > > I think automated builds (Jenkins/CI) could warrant its own list. > Separate lists would make setting up email filters easier in general. > > I like the idea of a list, like dev, but which does not include JIRA > comments or GH code review comments, and does not include Jenkins/CI This > would be a good way for potential contributors to have a light-weight way > of getting involved. If they are involved or interested in specific > issues, they can "watch" / "subscribe" to JIRA/GH issues and consequently > they will get direct notifications from those systems. Then people who > choose to get more involved, like us, can subscribe to the other list(s). > > We do have instances where "ASF subversion and git services" can be > excessive due to feature branches that ought not to generate JIRA posts to > unrelated issues, and I think we should work to prevent that. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Aug 7, 2019 at 7:01 AM Tomoko Uchida <[email protected]> > wrote: > > > Hi > > +1 for separated list(s) for JIRA/Github updates and Jenkins jobs. > While I myself am not in trouble with assorting the mails thanks to > gmail filters, I know an user (external dev) who unsubscribed this > list. The one reason is the volume of the mail flow :) > > Tomoko > > 2019年8月7日(水) 8:17 Jan Høydahl <[email protected]>: > > > Hi > > The mail volume on dev@ is fairly high, betwen 2500-3500/month. > To break down the numbers last month, see > https://lists.apache.org/[email protected]:lte=1M: > > Top 10 participants: > -GitBox: 420 emails > -ASF subversion and git services (JIRA): 351 emails > -Apache Jenkins Server: 261 emails > -Policeman Jenkins Server: 234 emails > -Munendra S N (JIRA): 134 emails > -Joel Bernstein (JIRA): 84 emails > -Tomoko Uchida (JIRA): 77 emails > -Jan Høydahl (JIRA): 52 emails > -Andrzej Bialecki (JIRA): 47 emails > -Adrien Grand (JIRA): 46 emails > > I have especially noticed how every single GitHub PR review comment > triggers its own email instead of one email per review session. > Also, every commit/push triggers an email since a bot adds a comment to > JIRA for it. > > Personally I think the ratio of notifications vs human emails is a bit too > high. I fear external devs who just want to follow the project may get > overwhelmed and unsubscribe. > One suggestion is therefore to add a new list where detailed JIRA comments > and Github comments / reviews go. All committers should of course subscribe! > I saw the Zookeeper project have a notifications@ list for GitHub > comments and issues@ for JIRA comments (Except the first [Created] email > for a JIRA will also go to dev@) > The Maven project follows the same scheme and they also send Jenkins mails > to the notifications@ list. The Cassandra project seems to divert all > jira comments to the commits@ list. > The HBase project has keeps only [Created]/[Resolved] mails on dev@ and > all other from Jira/GH on issues@ list and Jenkins mails on a separate > builds@ list. > > Is it time we did something similar? I propose a single new notifications@ > list for everything JIRA, GitHub and Jenkins but keep [Created|Resolved] > mails on dev@ > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <[email protected]> > For additional commands, e-mail: [email protected] > <[email protected]> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <[email protected]> > For additional commands, e-mail: [email protected] > <[email protected]> > > >
