On May 4, 2009, at 10:53 AM, Christian Geisert wrote:
Ean Schuessler schrieb:
[..]
Now a completely separate issue is how we determine whether
someone's changes are ready to go into the production repository.
In a Linus style model, it would just be up to David and then maybe
a lot of people would also follow Andy's branches closely (kind of
like the Linux Realtime patch series). On the other hand, we could
have some democratic +1 type thing going on about doing the merge.
Uh no, this isn't up for debate at the ASF ;-)
See http://www.apache.org/foundation/voting.html
Just to be clear I'm not really interested in that sort of role either
way.
It's an interesting model for the Linux kernel where more moderation
is probably in order, but I'm not sure it would be best for OFBiz...
and if it were you'd have to find another volunteer. At the minute I'm
so swamped with requests for feedback and watching commits as much as
I can that I simply can't keep up. This is one of the reasons I've
been encouraging others to review commits more and basically look for
problems because pretty much every patch has them, and I'll admit I
usually don't say anything because it's not a big enough issue at the
time.
Anyway, I do think a more open model is better, especially for a
project like OFBiz. My personal preference is to lead by example (or
by exception to example to demonstrate BAD practices, like by recent
following suit for the security stuff and not discussing before
committing, ie in many cases Commit-Then-Review is an evil thing), and
by principle, which is why I wrote what I wrote in the committers
roles and responsibilities doc:
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
What I mean by that is the "first do no harm" and "read before you
write" recommendations. It's hard enough for all of us to get along,
and when those rules (or recommendations...) are not followed it
aggravates things a LOT.
Back to Ean's point though: there is NO reason to hurry most things,
especially big changes like that have an effect on the ENTIRE project
and involve non-backwards-compatible changes that force data migration
when updating. It's FAR better to develop it in a way that doesn't
affect or break anything but that allows other people to check it out
and offer feedback. If that can be done in the trunk then I think it's
fine (the worst case scenario is you have to remove it) otherwise a
branch in the SVN repository, a patch in a Jira issue, or something
like Mercurial or GIT repos are a great way to go.
-David
