On Thu, Mar 10, 2016 at 5:30 PM, Adar Dembo <[email protected]> wrote:
> I wouldn't be opposed to moving gerrit traffic to another mailing list, > though I'd prefer it be reviews@ instead of reusing issues@ because I > think > that's more predictable and organized. I also think adding a guide to using > gerrit effectively for Kudu (linking back to the main gerrit guide) is > definitely not a bad thing. > > As for hiding certain gerrit notifications, I'm less sure about that. I > support the idea, but I also like the workflow of "upload a WIP patch (say, > without new tests), later upload a patch with unit tests and remove WIP > from the subject". I rely on the second e-mail to notify me that the patch > is now ready to be reviewed, and I think your proposed change would prevent > it from being generated, right? > I think so... though we could probably patch Gerrit to add a feature that sends a notification if the subject line changes. > > On Thu, Mar 10, 2016 at 5:19 PM, David Alves <[email protected]> > wrote: > > > +1 to all of the above. > > > > -david > > > > On Thu, Mar 10, 2016 at 5:17 PM, Todd Lipcon <[email protected]> wrote: > > > > > 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 > > > > > > -- Todd Lipcon Software Engineer, Cloudera
