Commit and Review (was "Is Lucene Java trunk still stable for production code?")

[Grant Ingersoll <gs...@apache.org>]

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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

Re: Commit and Review (was "Is Lucene Java trunk still stable for production code?")

[Chris Hostetter <ho...@fucit.org>]

Personally, i really like having a Jira issue number assocaited with every
commit ... and if there is a Jira issue open, attaching a patch is trivial
-- and having patches in Jira makes it a little easier for people who
really, Really, REALLY can't upgrade their version of lucene for some
strange reason still have an easy refrence point for when a feature was
added (and they can try to backport it).

I think the "Commit and Review" mentality is much more about how timid a
committer needs to be about big changes that *might* have consequences or
change APIs ... there are a lot of patches that don't break any existing
unit tests, but add some new public methods whose existence may be
questionable;  there are patches that change code and "fix" existing unit
test so that they still pass -- and these "fixes" might make the tests
logical, but raise the possibility that people were depending on the old
behavior; then there are patches thta change the way something works
internally, whose behavior was previously undefined; ... all of these
cases are things that a committer who feels they understnad the changes
should be able to go ahead and apply under the Commit and Review model,
becuase if there are any consequences, they can allways be rolled back
before the next release -- this is a luxary we haven't had in the past,
because so many people expected the trunk to be stable, and that they
could always "roll forward" using new methods and depending on new
behavior with risk that they would go away in a future release.

Ultimately big changes should always be discussed before they are commited
-- but where know we tend to have issues open for a really long time, with
lots of iterations of code patches before anything is ever commited, i
suspect we may eventually reach the point where issues are opened to talk about
*concepts* and hypotheitcal patches are attached showing off ideas, and as
people say "X makes sense, Y i'm not so sure about" X gets commited and
discussion continues about Y ... but if the game plan changes and X
becomes silly, we yank it back out.

we won't get from here to there overnight ... it's a deleicate dance
between the frequency of major releases, the mindsets of committers, and
the comfort level with doing patch releases to get bug fixes out because
you know the trunk has a lot of "X" stypes things in it that aren't relaly
stable.


: 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: java-dev-unsubscribe@lucene.apache.org
: For additional commands, e-mail: java-dev-help@lucene.apache.org
:



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

Re: Commit and Review (was "Is Lucene Java trunk still stable for production code?")

[Grant Ingersoll <gs...@apache.org>]

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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>

--------------------------
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org