Scott Gray wrote:
This may be where I'm not doing a very good job of explaining myself :-)
When I speak of a vote, I'm referring to a formal binding vote that
follows the ASF protocols (as David described below). In the past
this has only been necessary for the creation of release branches and
for major changes that have even the slightest disagreement or minor
changes that have major disagreement.
In that context:
1. Require Java 6 - So far there has been discussion and everyone
involved has now agreed to the change. I think the user list should
be notified of the proposal before setting anything in stone but if we
don't see any strong objections then I don't personally think a formal
vote should be necessary.
- Major change, formal vote if there is any disagreement
2. Remove Cloudscape support - No disagreement so far but possibly
worth mentioning on the user list but I don't think of this as a major
change and in the extremely unlikely event that someone wants to use
Cloudscape in the future then they can still get the files out of the
svn history and bring them up to speed with the trunk fairly easily.
- Minor change, formal vote if there are major disagreements
3. Remove Shark - This is a tough one because unlike Cloudscape the
Shark Engine is still alive and well outside of OFBiz and the odds are
a little higher that someone may want to use it in the future. Also
because no one is using it right now (that we know of) there is no one
to come out strongly in its defense. My personal opinion is that it
does almost no harm to keep it in the project and who knows, at some
point in the future having it there may sway a company to become
involved in OFBiz where they otherwise wouldn't have and while a good
portion of companies that use OFBiz don't really get involved in the
community and contribute, a single company deciding to do so can have
a major impact on the level of contributions coming in to the
project. So I feel that even if it is neglected, it is still a
feature of sorts and for this reason I would be a -1 for removal and
if people are really concerned about maintaining it then I would
gladly offer to check in on the component every now and again to make
sure it will still compile.
- Major change, formal vote needed
4. Add Birt to the trunk - This is really a non-issue because it
simply cannot be added in its current state even if a formal vote
concluded with +1000.
- Not yet ready to be a change, may require a vote if disagreement
remains (This is probably what you were getting at Tim, where the
component shouldn't be committed until some sort of community
consensus is reached, be it through a formal vote or simple discussion)
So in conclusion I think that what you are calling a vote is just good
community discussion (that happens to include +1s and -1s) which I am
wholeheartedly in favor of, rather than formal votes which I feel
should be used only when our discussions fail to reach a consensus.
In my original email I thought Adrian wanted to move the line where
discussion ends and a formal vote begins and it was this concept that
I was against (if that's even what he meant).
Regards
Scott
5. Is there a specific reason for keeping Old entities in trunk? Trunk
users should be already using the migration services and new entities?
Bilgin
