(Renamed; no other changes) https://cwiki.apache.org/confluence/display/LUCENE/Commit+Process+Guidelines
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Mar 4, 2020 at 8:36 AM Daniel Ruggeri <drugg...@apache.org> wrote: > 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 >> >
