lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <>
Subject Re: Commit / Code Review Policy
Date Fri, 06 Mar 2020 01:01:38 GMT
On Wed, Mar 4, 2020 at 8:36 AM Daniel Ruggeri <> 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: 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]
> P.S.
> Nabble, mbox, etc... they're OK, but have you tried Ponymail?
> 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

View raw message