Hi, all; I could have *sworn* I replied... but could find no record in my sent folder when David dutifully followed up with a ping. *facepalm*
Yes, I volunteered to participate and help where I can as a member of The ASF board, VP Fundraising, ComDev participant, or whatever hat I might be able to bring with me. Of course, I bear no special credentials here... we all hang out as volunteers. Reviewing the most recent board report[1], I detected: > We're discussing how to semi-require code reviews by defining project > guidelines. We invite a board member to help/advice how to navigate this > balance. So, yeah, here I am :-) My primary interest is to be sure we're approaching the discussion with community as our primary lens. I definitely reviewed the email thread, replies, and Confluence wiki document. In my interpretation of the discussion, a few things stood out: - There were some synchronous discussions that occurred off the list, which can lead to accidentally excluding important community voices from the conversation. By bringing the discussion back to the list before attempting to make a decision, the critical levels of transparency are maintained. This is definitely A Good Thing. - I perceived a lot of constructive feedback on the initial draft which appears (to me) to have brought the draft much closer to a document that represents consensus. Said another way, I don't detect conflict per se (please correct me if I'm wrong) - I think the feedback (and subsequent incorporation of that feedback into the guidelines) about exception cases like doc fixes and "small" changes is brilliant. On the httpd project, as a parallel example, we have a RTC policy for release branches except for docs - which are CTR. Indeed, a "docs committer" is the same as an "httpd committer"... we don't separate privileges because this social contract has worked well for 2 decades. - The current content of the document seems reasonable given the current environment. One thing that is unclear to me based on a quick browsing of the docs is what the branching strategy is for the project. What I gather is that the master branch is the release branch and features are added to master or merged in from short-lived feature branches. It'd be helpful to clarify this. - The proposed document draws additional parallels to things that work for httpd. Often times, we will share patches to the list for feedback before commits (similar to the Jira tickets proposed). We also operate trunk as CTR, but require 3 +1 backport votes to the long-lived release branches. This proposal has a similar net effect: bits that get released are (generally) intended to be "actively" reviewed before commit. It does fall short of requiring a consensus-style vote for release branches as httpd does... but that's OK. All told, this proposal seems quite reasonable to me because it has been discussed by the community, feedback has been incorporated, and the content of the proposal seems totally doable. That said, I'm open to other inquiries if there's something an external perspective can provide. How can I help? [1] https://whimsy.apache.org/board/minutes/Lucene.html P.S. Nabble, mbox, etc... they're OK, but have you tried Ponymail? https://lists.apache.org/x/thread.html/770ef83a8ed3a3d5d161c4a2cd812b4bdde47464d439c09ec31164dd@%3Cdev.lucene.apache.org%3E I'm a convert, for sure! -- Daniel Ruggeri Director, VP Fundraising, member, httpd PMC The Apache Software Foundation On February 7, 2020 9:14:37 AM CST, David Smiley <david.w.smi...@gmail.com> wrote: >I neglected to try and close up this long thread on the subject of code >review guidance. In the project's board report to the ASF, I asked for >help; Daniel Ruggeri (an ASF VP) graciously volunteered. He's on the >"To" >line to my message here; he's not a member of our dev list. > >Daniel: > >Thanks in advance for any assistance / guidance you have to offer. > >I suggest first reading through this thread: >https://lucene.472066.n3.nabble.com/Commit-Code-Review-Policy-td4452928.html >I find Nabble much easier to navigate than the ASF official archive, >but >that's here if you prefer: >http://mail-archives.apache.org/mod_mbox/lucene-dev/201911.mbox/%3ccabewpvet1u4xgxqadddhes+uybexmuw33c8fbs5bzdlzulc...@mail.gmail.com%3e > It starts November 26th and ended December 8th. > >The second thing is my proposal document stored in Confluence. I have >yet >to rename it as I said I would but I'll let it be for a little bit so >the >links continue to work for the moment: >https://cwiki.apache.org/confluence/display/LUCENE/Commit+Policy+-+DRAFT >Everything from "Tests" heading onwards has a "[PENDING DISCUSSION]" >notice >and can be ignored for the time being. > >~ David
