+1 I am generally wary of such proposals since they tend to impose hard processes in the places where trust should be dominant instead.
Apart from that, LGTM On Tue, 26 Nov 2019 at 14:46, Adrien Grand <[email protected]> wrote: > This document looks reasonable to me and a good description of the way > changes get merged today. Something it says between the lines and that > is the most important bit to me is that this isn't really a policy but > rather a set of guidelines, and that we trust each other to do the > right thing. Maybe we could better reflect this in the name, e.g. > "Commit/Merging guidelines". > > On Tue, Nov 26, 2019 at 6:34 AM David Smiley <[email protected]> > 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 > > > > -- > Adrien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards, Atri Apache Concerted
