yes David: I read the document, I'm against both the contents of it, and how it came about. For example there is no "silence is consensus" which is really important to me. If you work full-time on this shit for some large company X, this is probably of no concern to you.
But it matters to me. For example, I opened some patches to improve solr's security because its currently an RCE-fest. I'm gonna wait a couple days, if nobody says anything about these patches I opened for Solr, I'm gonna fucking commit them: someone needs to address this stuff. Why should I wait weeks/months for some explicit review? There is repeated RCE happening, how the hell could I make anything worse? Please don't add unnecessary things to this document like "Linear git history" which have nothing to do with code reviews. Its already controversial as its trying to invent its own form of "RTC", you aren't helping your cause. On Mon, Dec 2, 2019 at 12:35 AM David Smiley <[email protected]> wrote: > Hello Rob, > > On Sat, Nov 30, 2019 at 9:39 AM Robert Muir <[email protected]> wrote: > >> On Tue, Nov 26, 2019 at 12:34 AM David Smiley <[email protected]> >> wrote: >> >>> Last Wednesday at a Solr committers meeting, there was general >>> agreement... >>> >>> 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. >>> >> >> -1 ... you even went so far as to discourage lucene committers from >> attending that meeting, and now its turned around as if its consensus >> everywhere and should be applied to lucene too? >> > > I'm looking back over what I wrote. I suppose it's this self-quote that > bothered you?: > >> This particular committer's meeting has a particular subject/theme. So >> as Erick indicated, while all committers are invited, I think if you're >> not interested in the subject then I'm sure you can find a better use of >> your time. > > Personally I think what I stated there is reasonable. More importantly, > both me and Erick also expressly declared all committers are welcome. If I > actually meant otherwise then I wouldn't have said so. > > >> I don't think changing things to review-then-commit will help. >> > > I don't think *anyone* wants ASF's RTC due to the "consensus approval" > requirement with three +1's -- > http://www.apache.org/foundation/glossary.html#ReviewThenCommit *My > proposal says this up front clearly* (I think). Did you read it? I > don't think Shawn read it either -- I'm not calling for an official change > to RTC. Here's the link again: > https://cwiki.apache.org/confluence/display/LUCENE/Commit+Policy+-+DRAFT > I can copy-paste it here if you like which would also serve to snapshot > exactly what I'm talking about. > > I observe that we seem to mostly follow this guideline document already, > particularly what I observe in Lucene (less so Solr). No not all the > details and all the particulars I wrote on what constitutes "minor", but > the gist of the review/approval. We don't just commit at will today; we > wait for reviews and get them. I'd like what we do today (in Lucene) > written down more clearly for everyone's benefit -- new/interested people > and ourselves. This document is my attempt to do that plus raising the > review/approval guideline norms *just a little bit* (IMO). For Solr it's > more than a little bit, granted. Then I can point others at this, and if I > see behavior that got no review for something where it was warranted > (according to documented guidelines), I can reference this. > > Lets say we accept these new guidelines. After six months, we can > change/loosen our practices and edit this document accordingly. It's just > a guideline document. (Credit to Thömas on this good point) > > ~ David >
