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]
