My (non-binding and perhaps misguided) $.02.
I think...
- Normal dev process should apply to trunk, regardless of perceived stability,
especially prior to 1.0. We should "get it right"
- Anyone can develop anything they are interested in.
- Commit early and often, and review (the more eyes the better).
- Note that this assumes the developer has done due-diligence and
tested their code using all available means (TCK, embedded tests, etc).
- Committing early and often means commits are smaller and easier to
review.
- Commit-then-review allows others to easily grab a level of code from
the repository and try it themselves. It also keeps history with the
code instead of in separate mailing list where date is the only link.
- This assumes
- If reviewed code proves to be problematic it can either be fixed or
reverted. No harm done (other than some wasted time).
- If variants of this discussion have happened multiple times, perhaps some
of the details need to be included in the code as comments.
- If we aren't getting the reviews we need then we might need to force things a
bit. Perhaps we should require a certain number of +1 reviews in JIRA before
the
issue can be closed.
- Note that Mark's assumption that "lack of reviewers = code too complex"
isn't necessarily the issue here. It is one possibility, but it's also
possible
that others have simply seen the code as working and focussed elsewhere,
they were lazy and let the "expert" do the work, or any number of other
motivations (or lack thereof). The complexity of the code should speak
for (or damn) itself.
- As this code gets used by others in more complex environments, we're going to
see
more people trying to scratch their own itches. The better we do at
documenting the
code (comments in code or JIRA) and the better we do at driving out
unnecessary
complexity, the more likely we are to have useful contributions and reasonable
questions. If Mark can't remember why things are the way they are or can't
easily
figure it out from the code, what is the likelyhood that new user or
contributor
will be able to figure things out and make useful changes?
So I say, let Mark give it a shot. He's proven pretty reliable in the past. :)
His changes are likely to evolve and be refined as he works with the issue.
We need to critically review it to verify that it is an improvement and that
nothing breaks, and Mark needs to do due-diligence before committing so we don't
waste our time reviewing something that ends up needing to be reverted.
Paul J. Reder
On 03/24/2010 09:27 AM, Gurkan Erdogdu wrote:
One point I want to share is that, it is not easy to implement those
concepts in couple of days. It takes lots of time and appreciate it if
you look at>>>when this project is started. I think that we have reached
a very good point because of lots of TCK (even all) has passed after
long nights.>>>Therefore it takes responsibility to commit something that
changes things completely. But I do not say that or else imply that I
am the owner and>>>all of my code is correct. Code has owned by the
Apache community and it needs lots of update. My main point is that you
may not change>>>something if it does not work for your
environment/project.
Anyway, those are just my 2 cents!
What others think about this? Is it ok to commit something when owner think
that it is OK from his side? My concern is that if we change something that is
under the danger zone, at least it does followings;
* Passes all of our internal tests
* Runs against TCKs and it must pass tests that latest codebase is passed
* And if we have time, tests our examples. Actually we have a great number of
examples for different environments.
Thanks;
--Gurkan
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
