Mystery authors seem to be - Hoss https://web.archive.org/web/20071011105632/http://wiki.apache.org/solr/CommitPolicy <https://web.archive.org/web/20071011105632/http://wiki.apache.org/solr/CommitPolicy> - Grant https://web.archive.org/web/20090504015648/http://wiki.apache.org/solr/CommitPolicy <https://web.archive.org/web/20090504015648/http://wiki.apache.org/solr/CommitPolicy> - Myself https://web.archive.org/web/20111119003001/http://wiki.apache.org/solr/CommitPolicy <https://web.archive.org/web/20111119003001/http://wiki.apache.org/solr/CommitPolicy> :)
This should probably be part of the new Dev Guide? But go ahead draft in in Confluence first! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 26. nov. 2019 kl. 06:34 skrev David Smiley <david.w.smi...@gmail.com>: > > 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 > <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 > <http://www.linkedin.com/in/davidwsmiley>
