And by break, I mean all tests pass with the possible exception of
those related to the new functionality.
Also, the example I gave about payloads is hypothetical. I'm still
going to submit a patch.
On Mar 17, 2007, at 12:02 PM, Grant Ingersoll wrote:
Hoss wrote:
> (or in short: we're moving more towards a *true* commit and
review model)
I'm curious as to what you think are the practical implications are
for committers for this model? Do you imagine a change in the
workflow whereby we commit and then review or do we stick to the
patch approach as committers (contributors will always submit
patches)? It has always been a gray area, where we all kind of
know what we can commit w/o creating patches for versus what we
should put up patches for. Just curious, I'm working on the
payloads stuff and I know that as long as it compiles, it isn't
going to break anything, so in some sense I could commit b/c I know
it would make it easier for Michael B. and others to update and
review w/o going through the patch process. On the other hand, the
patch approach makes you take one extra good look at what you are
doing.
What do others think?
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
