I think more is needed going forward. What I would like to see is an explicit "risks" section of the jira that shows the committer has thought about the different risks to the system before committing code that effects the core. The committer should take time to understand what part of the system might be effected. This will do two things:
1) Force the committer to think more about how there change affects the rest of the system. 2) Helps other committers understand the risks so that there is more incentive to get involved and test. Joel Bernstein http://joelsolr.blogspot.com/ On Tue, Nov 26, 2019 at 4:26 AM Atri Sharma <a...@apache.org> wrote: > +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 <jpou...@gmail.com> 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 <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 >> >> -- > Regards, > > Atri > Apache Concerted >
