On Wed, Mar 4, 2020 at 8:36 AM Daniel Ruggeri <drugg...@apache.org> wrote:
> 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 agree 100% in what you said. I thought about this principle as I conducted my business (off-list and on-list). I'm frustrated that not everyone agreed; I really do care! If we are so fearful of crossing a line here, then we end up limiting ourselves to excluding opportunities to see each other and hear each other's voices, and that would be shame! A lot can be lost in purely text chat in ascertaining emotion / intent. Seeing and hearing each other can help diffuse possible conflict and furthermore it enriches our relationships in subtle ways. Do you agree? Do other projects have written guidelines that we can adopt to state this more concretely so we don't cross a line? > - 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 agree; it was all constructive. > - 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. > Thanks! Documenting this is important to me as too often I see too much ceremony for such trivial stuff which in turn leads to reduced contributions from me because I don't want to go through that ceremony when I don't think it's warranted. > - 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. > True; we should probably state the strategy _somewhere_; maybe this document is where. Although such info wouldn't really be guidance/advice so I'm not sure it goes on the document. We branch off from our main/dev branches to do releases, and so I wouldn't call "master" and "branch_8x" release branches since we do have actual release branches created at feature-freeze time. > - 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. > Hmmm. What we do is have the release manager be a required gatekeeper as to what may be committed to a release branch (yay/nay decision maker), and we know basically what the general qualifications are which are repeated at every feature freeze. This document would be a good place to state them; good idea. > > 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? > I suppose we're in good shape then. I have one question that you more than others could give an authoritative answer to: Do projects really choose RTC: http://www.apache.org/foundation/glossary.html#ReviewThenCommit given the onerous requirements? It's hard for me to imagine it being workable unless there were lots of active committers and if the volume of change is low and if the changes are potentially sensitive (e.g. for encryption). If the Lucene project hypothetically wanted to insist on at least one +1 from someone, would we not be able to call this RTC because it doesn't meet the definition above? I suspect in truth we can define our policy as we wish. > > [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! Thanks for showing me Ponymail! It's *way* better than whatever that interface is for mod_mbox URLs. Our project website should replace all such links to Ponymail. ~ David
