I don't think anyone followed-up on this. I think I prefer our current approach, where contributors provide patches, everyone is free to review and comment on them, and commiters finally commit it. Feels a bit slower than commit first, review second, but I think that makes it easier to control the quality of the code that goes in. There seems to be enough momentum/active developers that even with the current patch first approach we could release more often.
Otis ----- Original Message ---- From: Grant Ingersoll <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Saturday, March 17, 2007 12:02:55 PM Subject: Commit and Review (was "Is Lucene Java trunk still stable for production code?") 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]