lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anshum Gupta <ans...@anshumgupta.net>
Subject Re: Commit / Code Review Policy
Date Mon, 02 Dec 2019 18:18:16 GMT
Thanks David, and every one else here.

Let's not call this policy, as 1. there are folks other than me who think
that's too strong a word for what we are trying to do here, 2. this has
"rules" that we will have to ignore based on the circumstance. these rules
should instead be recommendations, and the policy be either what Robert or
Tomas suggested i.e. Recommendation/Guidelines.

I feel that the document might be read in a different context by people who
weren't in the meeting. As far as I understand, the intention here is to
have better quality commits, with involvement of more than one person,
especially when the changes are large and affect the core/API.

There are points around adding tests, which also directly are about just
improving code quality, something that has led to the failing tests and
other issues that have been spoken about in the recent past.

+1 on adding something explicitly about "silence is consensus".
There are certain parts of the code that aren't worked by more than a
couple of people and in that case, these points will have to be just
interpreted based on the situation.

Overall, I really think it will not only be awesome  but is critical to
have more people reviewing code and for larger changes to be discussed
instead of being pushed in.


On Tue, Nov 26, 2019 at 11:04 AM David Smiley <david.w.smiley@gmail.com>
wrote:

> Last Wednesday at a Solr committers meeting, there was general agreement
> in attendance to raise the bar for commit permission to require another's
> consent, which might not have entailed a review of the code.  I volunteered
> to draft a proposal.  Other things distracted me but I'm finally thinking
> of this task now.  *This email is NOT the proposal*.
>
> I was about to write something from scratch when I discovered we already
> have some internal documentation on a commit policy that is both reasonably
> well written/composed and the actual policy/information is pretty good --
> kudos to the mystery author!
>
> https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy
>
> I'd prefer we have one "Commit Policy" document for Lucene/Solr and only
> call out Solr specifics when applicable.  This is easier to maintain and is
> in line with the joint-ness of Lucene TLP.  So I think it should move to
> the Lucene cwiki.  Granted there is a possibility this kind of content
> might move into our source control somewhere but that possibility is a
> subject for another day.
>
> I plan to copy this to Lucene, mark as PROPOSAL and then make some large
> edits.  The diff will probably be kinda unrecognizable despite it being in
> nice shape now.  A "Commit Policy" is more broad that a "Code Review
> Policy"; it could cover a variety of things.  For example when to commit
> without even filing a JIRA issue, which I think is worth mentioning.  It
> should probably also cover Git considerations like merge vs rebase, and
> multiple commits vs squashing.  Maybe we should also cover when to bother
> adding to CHANGES.txt and "via"?  Probably commit message requirements.
> Snowballing scope :-). Probably not JIRA metadata as it's not part of the
> commit to be part of a commit policy, but _somewhere_ that's needed.  I'm
> not sure I want to  sign up for all that now but at least for the code
> review subject.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>


-- 
Anshum Gupta

Mime
View raw message