This one time, at band camp, Keith Visco said:
KV>That's a very difficult question to answer. To be direct, the current
KV>committers are the only ones with actual CVS write access. So in the
KV>end, patches and enhancements must be commited by those with write
KV>access. So the committers must agree that the changes are actually
KV>beneficial to the community in general before committing them.
KV>
KV>If the many users really want a feature and someone is willing to write
KV>and test the feature, then I see no reason why it would not be accepted.
KV>
KV>On the other hand if one person writes a patch and the patch is highly
KV>specific to the individuals case, it might not be accepted. The patch
KV>can be made available to the public via the list or any other means the
KV>user may have at his or her disposal however.
KV>
KV>However, in both of these cases the community is really controlling the
KV>direction, because user-demand or user-non-demand can cause features to
KV>be accepted or rejected.
KV>
KV>In the end however, the decision will ultimately come from the
KV>committers. A reason will always be given for not accepting a patch and
KV>the community can comment about whether they agree or disagree.
This is very much like any other Open Source project. There are
many people who contribute by way of a member or committer on the
project. The difference with Castor JDO is that we (the committers)
have really been pushing to help others understand the JDO test
framework. This helps them understand that a patch for one thing
may break other things. It also is a good demonstration of what the
committers go through to test a patch before accepting it (on our
own personal time ;-)).
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
