On 4/27/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
1. Solr usually works in RTC mode:
I don't think that's really the way we have been working (RTC requires a consensus vote). I think we've been doing CTR. For anything non-trivial, we open a JIRA issue and request feedback before committing. Feedback is not always received, but I've still committed many based on my own personal comfort level with the patch (if I think it will be contentious or not, etc). So it's more like lazy consensus. I think Solr has been using roughly the same approach that Lucene-java has been (unsurprisingly, since that's where many of us came from).
3. Patches, and especially those adding new functionality, must be accompanied by automated tests and some documentation (usually in the Solr wiki).
In general... I like guidelines more than rules, and I like to retain flexibility. My *personal* philosophy is probably more permissive than most: - a half baked patch in JIRA is better than no patch at all (just say it's not quite ready) - a JIRA patch w/o tests is better than no patch at all - new functionality w/o a test is often better than no functionality (some tests are very hard to write... I've just hand-tested some things in the past). - new functionality with tests is better than without - new functionality that's not documented is often better than no functionality (it doesn't have to be at the same time... it can be documented later) - new functionality with tests and documentation is best Off on a tangent: for contributors, we want to be careful about implying that patches should always be complete, include unit tests, and be documented. While it's nice, we'd still rather have a patch than no patch at all. Of course if someone is looking to become a committer, then we would be looking at patch completeness, quality, tests, etc. -Yonik
