On Wed, 1 Nov 2006, Greg Monroe wrote:
I mostly agree with your strategy here. It's in line
with what Maven does for Contributed plug-ins. There's a
http://maven-plugins.sourceforge.net/ project for a wide
variety of things that aren't licensed under Apache, etc.
The only thing I might question is this being a blanket
policy with no respect for size. In the case of my
submission, this probably does belong on SourceForge.
It's fairly large.
But what about small contributions, like the XML style
sheet to convert schema XML to ERDDesigner XML format?
Or a future submition that's a single template override
file that supports INNOB table hints in MySQL. Should
contributers of stuff like this have to create an
external distribution site?
I'd hate to see solutions to some of DB version
specific problems not solved because it's hard to
contribute.
I agree with you here. The points were made because of the cost of quality
assurance and maintenance, and for small additions, this might not apply.
Personally, I'd even consider the InnoDB hint stuff as core Torque, and
include it into the main distribution.
I would also not mind to check your betwixt add-on, and I'm sure I would
not have to fear much in terms of quality there, but I just do not see me
revising addons every time, so I did not want to open the door in the
first place.
But then I guess I could request a Torque-Add SF.net
project and make it a generic place to find such stuff.
If you want to do this- great !
Thomas
-----Original Message-----
From: Thomas Fischer [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 29, 2006 5:48 AM
To: [email protected]
Subject: Handling of custom add-ons
Hi all,
I'd need some opinions whether we should add custom add-ons
to the Torque svn.
A short summary of the situation: Greg has submitted a patch
to the generator (TORQUE-50) which allows to easily create
add-ons to the generator templates. This patch is already in
svn and will be in the 3.2.1 version.
Now the question is how we should handle such addons. E.g.
Greg has submitted an addon which adds support for XML import
and export of Torque objects using betwixt. This is certainly
a useful feature for some users of Torque. The question is
now whether we want to keep such addons in the Apache svn or not.
My problems are the following:
- A committer must review the code that is commited to the
repository.
Speaking for me personally, this needs time I would otherwise
have used for core Torque code. There are lots of things to
do for core Torque code, so I'd rather not spend time for
reviewing addons, which can take lot of
time: People expect Apache software to be quality software.
To ensure this, a careful review is needed, so the a
superficial review will not do.
- The second concern is the maintainance concern. Users
expect Apache software to be maintained. This would mean that
someone would have to make sure that an addon still works
with newer versions of Torque, and apply changes to that if
it doesn't. For the reasons outlined above, I am not prepared
to to that.
Personally, I belive the better solution would be to host the
add-ons externally, e.g in a sourceforge project, and keep
links on the Torque page to them. This solution would not
have any problems outlined above. I would be happy to
maintain links to the externally hosted add-ons on the Torque site.
Any other opinions ?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are
confidential communication or may otherwise be privileged or confidential and
are intended solely for the individual or entity to whom they are addressed.
If you are not the intended recipient you may not rely on the contents of this
email or any attachments, and we ask that you please not read, copy or
retransmit this communication, but reply to the sender and destroy the email,
its contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is strictly
prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
