Here's my understanding of our current (but largely unwritten IIUC)
way of working.
1. Solr usually works in RTC mode: patches are first posted to Jira,
then committed once we agree on a particular patch. This does not
apply to obvious fixes, typos, etc., of course.
2.. Non-trivial patches require a [VOTE] on the dev list before being
committed. What's "non-trivial"? I'd suggest using our common sense
and trusting each other to judge this, for a start.
3. Patches, and especially those adding new functionality, must be
accompanied by automated tests and some documentation (usually in the
Solr wiki).
4. If needed, we could create svn branches for wild experimental
stuff, but we prefer to work with small incremental patches if
possible.
I hope I'm not wasting our collective time with this - feel free to
correct, complete, flame, whatever ;-)
yes. Clarity is good!
The logic I had for this set of commits was adding things that are
trivial (SOLR-203) and things that do not affect a running system
without configuration (SOLR-162, SOLR-179, SOLR-211) -- Next time i will
wait for an explicit review + vote.
My "trivial" radar may have been off when I deleted ContentStream.java
and CommitRequestHandler.java with only a warning on the wiki...
yes, these guidelines look good
ryan
