One more action item: I think a lot of the "useless" traffic from gerrit to the list is people uploading a new revision of an existing patch. It looks like I can disable this and only have it post new reviews and comments, and not bother posting "submitted" or "new revision".
Of course if you're a listed reviewer (i.e have reviewed a previous revision) you'll still get notices when someone updates the review or submits it. Are people cool with this? -Todd On Thu, Mar 10, 2016 at 5:04 PM, Todd Lipcon <[email protected]> wrote: > Thanks, JD, Mike, and Adar for jumping in with more perspectives. > > I'm afraid that this thread might take a turn towards an unproductive > argument of "tooling vs mailing lists", but I don't think that was Chris's > main point. Neither do I think Chris is just trying to stir up trouble -- I > approached him about being a mentor for our incubation because I've always > found his advice to be unbiased, measured, and helpful towards building a > good community. > > To try to drive this to a useful conclusion, let me propose a few action > items: > > 1) Let's move gerrit traffic to a different list as discussed. I think > many of us already did filters like this for our own inboxes, but the point > about the archives being hard to read is a good one. I have a slight > preference to reuse the issues@ list instead of a new reviews@, both to > keep the number of lists down, and because we often discuss and fix bugs > more on gerrit than through lots of JIRA commentary. Makes sense that the > filing of a bug, and its discussion/fix, would show up on the same list. If > others disagree, though, I think reviews@ would be fine as well. > > 2) Chris also makes a good point that it's hard to extract signal from > noise in the flood of gerrit traffic. Slowing down development isn't a > great option, but I think we can use gerrit to our advantage here. It > actually allows users the ability to selectively watch certain paths in the > repository, which would be very helpful for new contributors who might for > example care a lot about changes to python/* but not to our consensus > implementation. Others might care a lot about design-docs/* for more > architectural discussions. I'll volunteer to write up a new section in our > 'contributing' guide that shows people how to selectively subscribe to the > areas of code they're interested in. > > Chris -- do the above items seem like positive changes from your > perspective? Are there any other concrete action items you think we should > consider? > > -Todd > > > > On Thu, Mar 10, 2016 at 4:39 PM, Adar Dembo <[email protected]> wrote: > >> Hi Chris, >> >> I'm a new Apache committer and new to ASF in general. I have some >> experience with other open source projects, and as a developer I value the >> "advanced" tooling that many have adopted. If we assume >> everything-is-over-email as the baseline, this tooling includes: >> - Chat rooms for real-time communication, be it via IRC, Slack, HipChat, >> etc. >> - Code review tools a la Review Board. >> - Complete workflow management tools a la GitHub, gerrit, etc. >> - Bug report trackers a la Bugzilla, JIRA, etc. >> Many of these tools are offered by Apache, so it seems like Apache's trend >> is towards "the right tool for the right job" rather than "everything must >> be communicated over e-mail". >> >> In particular, as someone who does a high volume of code review on Kudu >> and >> other projects, I'll strongly value advances in review tooling. Taken >> together, they can save me hours of time in a given week. As for design >> review, Dan and I discussed this at length when we transitioned from >> Google >> Docs to gerrit. You can see our back-and-forth here: >> http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find the >> "centralized commenting" approach of a system like Google Docs or gerrit >> to >> be more useful than an e-mail thread, especially when one wants to look >> back at a design discussion that took place in the past. >> >> Generally speaking, I suspect that moving more of Kudu's development on >> mailing lists optimizes for the casual developer who rarely contributes >> patches but wishes to "stay involved" in numerous Apache projects. I don't >> think we should be optimizing for this person; I'd prefer we optimize for >> folks who have deliberately decided to invest their time in Kudu, because >> they're thinking of using it to solve a problem, because they're already >> using it, or because they find the technology to be just plain >> interesting. >> These developers will adapt themselves to whatever workflow the project >> uses, are likely to produce large contributions, and are more likely to >> appreciate some of the more advanced tooling that Kudu uses. >> >> Personally, I don't like being asked to slow down my workflow purely on >> the >> faith that it will spur OSS adoption. What I see is someone who is not >> involved in Kudu's day-to-day activities requesting we make changes that, >> I >> think we both agree (in your words, "Email is slow and deliberate and not >> as fast or slick as gerrit etc, but that's a good thing"), will slow down >> Kudu development. Further, I see a blanket dismissal of Todd's (very >> reasonable) counterpoints. So I'm naturally being defensive; can you >> provide more substantive arguments as to why we should move development >> discussions off of tools like gerrit and onto the dev mailing list? >> >> >> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) < >> [email protected]> wrote: >> >> > Thanks for the reply Todd. Unfortunately it's more systematic than that. >> > Apologies for top post but am on my phone. Couple points: >> > >> > - interested to hear from others besides you on this. No offense but I >> > think it's important that project members send email here to reply. >> > >> > - I hand counted the 4 threads of interest. Didn't run a fancy command >> but >> > to be honest it's more indicative of the broader issue. Things aren't >> > always solved through fancy greps and tools like gerrit. This is going >> to >> > be a core issue with Kudu's incubation - how is someone not sitting in a >> > cube working on the project who isn't on those tools like gerrit and >> slack >> > which don't exist at the ASF going to join on the project? >> > >> > - Even considering 40 threads I doubt there have only be <= 40 >> *decisions* >> > on the project to date. IOW they are being made somewhere but it's >> unclear >> > where. Email is easy to follow on a phone on the go whatever. >> > >> > As a mentor I would not be comfortable with Kudu being a TLP at this >> point >> > bc frankly projects need to use their dev list for more than automated >> > discussion and big reports. Simple as that and sending a transcript of >> > where convo is happening elsewhere is not going to cut it unfortunately. >> > >> > Email is slow and deliberate and not as fast or slick as gerrit etc, but >> > that's a good thing. It allows people the time needed to read and join >> an >> > OSS community. It's too hard to do that with Kudu right now. >> > >> > Cheers, >> > Chris >> > >> > Sent from my iPhone >> > >> > > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <[email protected]> wrote: >> > > >> > > Hey Chris, >> > > >> > > Responses inline: >> > > >> > > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) < >> > > [email protected]> wrote: >> > > >> > >> Hi Team, >> > >> >> > >> I looked at: >> > >> >> > >> https://mail-archives.apache.org/mod_mbox/incubator-kudu-dev >> > >> >> > >> And over the last 4 months and Kudu’s inception, we have had >> > >> well over 2k+ emails, and looking back I found 4 actual threads >> > >> during that time (and one of which was a release VOTE thread) >> > >> that wasn’t automatically generated by Gerrit. >> > >> >> > >> Mar 2016 438 >> > >> Feb 2016 1003 >> > >> Jan 2016 1143 >> > >> Dec 2015 12 >> > > >> > > Hmm, I did a search in my inbox for: [email protected] >> > -gerrit >> > > -jira -"git commit" -dev-help -"svn commit" -moderate -"git push >> summary" >> > > and counted 30-35 threads. You're right, of course, that JIRA and >> gerrit >> > > eclipse the amount of email discussion, though. >> > > >> > > >> > >> >> > >> >> > >> If we are going to become an ASF top level project, the project >> > >> discussion has to happen on the mailing list. We had similar >> > >> issues in Spark and I realize that lots of project work is assisted >> > >> by tools and other technologies, but at the ASF, “if it didn’t >> > >> happen on the mailing list, it didn’t happen.” More-over it’s hard >> > >> to parse signal from noise in all these automated messages. Frankly >> > >> I don’t really know if anything good is going on - I know things >> > >> are going on, and I assume they are good, but it’s extremely hard >> > >> to verify that. >> > > >> > > I think it's worth noting that the "automated' messages are typically >> > code >> > > review requests and responses, which are developer discussion. Our >> > > project's culture is usually to use JIRAs and/or 'work-in-progress' >> > patches >> > > in gerrit to communicate when we find a bug or want an opinion on >> > > something. For example, today I found a new bug >> > > https://issues.apache.org/jira/browse/KUDU-1369 and wrote up a quick >> > > work-in-progress for a a proposed solution and put it up at >> > > http://gerrit.cloudera.org:8080/#/c/2514/ . I think it would be >> > redundant >> > > to also send an email to the list saying "Hey guys, I found a bug, >> > here's a >> > > description". >> > > >> > > The same goes for design discussion -- eg >> > > http://gerrit.cloudera.org:8080/#/c/2443/ is a recent gerrit post >> that >> > Dan >> > > made for a new feature he's working on. In this case he also sent an >> > email >> > > to the dev list to point out the gerrit in case anyone missed it. I >> > imagine >> > > a lot of people would filter the gerrit emails out of their inbox but >> not >> > > direct emails to the list (gerrit provides both headers and a subject >> > line >> > > tag to make it easy to do) >> > > >> > > In terms of daily dev discussion, most of it has been happening on our >> > > Slack -- eg earlier today three contributors were discussing >> in-progress >> > > efforts on Spark RDD integration and sharing code via that channel. >> Most >> > of >> > > the community members we've seen so far have tended to prefer this >> quick >> > > back-and-forth for discussion. >> > > >> > > Of course any _decisions_ will be made on the mailing list. If you >> think >> > it >> > > would be useful to send a daily slack log to the mailing list, we can >> do >> > > that as well. >> > > >> > > >> > > >> > >> >> > >> I have a possible suggestions: >> > >> >> > >> * Create a [email protected] and send all automated >> > >> traffic there. *-issues is one option; we could make another name for >> > >> it. >> > > >> > > Sure, we could do that. But, isn't it just as easy for people to set >> up a >> > > filter for 'kudu-CR' if they want to move those messages elsewhere? >> Our >> > > initial motivation when setting up mailing lists was to avoid having >> too >> > > many (makes it a pain for people to subscribe to them all). >> > > >> > > >> > >> >> > >> That will help to separate the signal from the noise in terms of >> > >> dev/architectural/etc. discussions from code reviews and automated >> > >> commit messages. >> > >> >> > >> One thing you may say is that dev/architectural discussions are >> > happening >> > >> but they are in Gerrit. I would then say it’s extremely difficult to >> > >> separate the signal from the noise here, and as such, could be >> > contributing >> > >> towards making it difficult for others to join the project, something >> > >> that we identified as an issue in our Incubator report. >> > > >> > > Right. One option is that, for patches with bigger discussion, we can >> > add a >> > > gerrit "reviewer" which is actually the dev mailing list. This would >> > cause >> > > the discussion to be CCed there, and bring it to the attention of more >> > > people. Another thought is to do as you suggest above and move gerrit >> > > elsewhere, and just have a policy that whenever any gerrit starts >> getting >> > > architectural, that we send a ping to the dev mailing list to point it >> > out >> > > (as Dan did with his recent design doc). >> > > >> > > -Todd >> > >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera > -- Todd Lipcon Software Engineer, Cloudera
