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 <david.w.smi...@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 -- Adrien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
