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: [EMAIL PROTECTED]
: For additional commands, e-mail: [EMAIL PROTECTED]
:



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to