Glen, Benson, and Apache CXF team,
Here are my responses to Glen's comments/observations related to my
contributions.
Glen's comment: "But, also, as for the issue of time you mention, this
brings up an earlier
concern I had about the expansive "thank you" page you recently made
(http://cxf.apache.org/special-thanks.html), in which you list and explain
every Apache and other project that CXF imports, as well as (IMO)
erroneously list Apache-wide helpers like Atlassian that should be thanked
at an Apache-level and not individually within every project. "
Robert Response: I returned the "thank you" page to the version it was at
before I touched it. I also returned the "Architecture Guide" page to the
original version, as I had left it in a flux state and do not plan or have
the experience to finish it in the proper manner.
Glen's comment: "One should also analyze the opportunity cost of making the
command line
options looking the same as the GNU conventions compared to adding
additional functionality to CXF,..."
Robert's Response: The definitions of the command line options are different
in at least three different places. Some of the inline usage definitions
don't even match what the tool actually does. For the most extreme example,
the usage for "idl2wsdl", starts out with "idltowsdl"; just do a
"idl2wsdl -help" to see for yourself. "Cleanup" was my intent of the issue
raised, meeting conventions in the process is considered a "best practice"
and would be nice to the end-user community if achieved.
Glen's comment: "... a similar issue to your earlier desire to have the CXF
website be reformatted to look like Camel, ServiceMix, and ActiveMQ's."
Robert's Response: It was my general feeling that ASF projects should be
branded in a similar fashion. However, it's been made to clear to me by
several people at ASF that forcing branding does not work well with
open-source.
Glen's comment: "So as you enhance the CXF documentation, please be sure
that you're not
giving CXF "puppies as presents", things that look cute but are of
relatively limited benefit and need a lot of maintenance afterwards to
remain cute. "
Robert's Response: I'm definitely not on the same page as the CXF team. It
was a nice stay. If any of my other updates seem that they do more harm
than good, please revert the web pages back to old instances. I'm not going
to fall anything else back, as I feel that has been value in my improvements
to the web-pages content.
To wrap things up on my side, I'll look at the issues I have opened and will
try to align them with the general open-source philosophy.
Take care,
Robert
-----Original Message-----
From: Glen Mazza
Sent: Thursday, November 11, 2010 10:30 AM
To: [email protected]
Subject: Re: Apache CXF tooling usage definitions
Robert Liguori wrote:
Note that I personally don't have time to contribute to this, but I do
think
that refined, synchronized and more accurate usage definitions would bring
enhanced 'polished' value to the product.
Several of your suggestions Robert would seem better suited for the CXF-Dev
rather than the CXF-User's list. For any project, not just CXF, many ideas
look excellent at first glance but for various reasons are known not to be
such a great idea by developers and close observers who have spent years
with the project. However unfair given all your work on the documentation,
heavy usage of CXF-Users over CXF-Dev can give the impression that you
realize that a lot of your ideas hold less and less water the more
experienced one is with the project and that you are using the User
community to unduly push sweet-looking-on-the-surface changes that perhaps
should not be made.
One should also analyze the opportunity cost of making the command line
options looking the same as the GNU conventions compared to adding
additional functionality to CXF, a similar issue to your earlier desire to
have the CXF website be reformatted to look like Camel, ServiceMix, and
ActiveMQ's. Another factor is that volunteer developers need to work on
tasks that further themselves first and busywork (or "polishing") rarely
accomplishes that. For open source to be successful, a volunteer developer
should always be *stronger* as a result of volunteering on an open source
project, not weaker.
But, also, as for the issue of time you mention, this brings up an earlier
concern I had about the expansive "thank you" page you recently made
(http://cxf.apache.org/special-thanks.html), in which you list and explain
every Apache and other project that CXF imports, as well as (IMO)
erroneously list Apache-wide helpers like Atlassian that should be thanked
at an Apache-level and not individually within every project. No question,
it looks very nice and professional now, but who's going to be maintaining
this? It's like you're giving us a new puppy as a present. This page is
not going to be looking very nice in several months once it falls out of
date, links get old, etc. It's not necessary for an Apache project to have
to individually thank every other Apache project it incorporates. The
source of record for determining the dependencies used by CXF is always
going to be its POM files or the lib folder of its distribution, not a
website page.
So as you enhance the CXF documentation, please be sure that you're not
giving CXF "puppies as presents", things that look cute but are of
relatively limited benefit and need a lot of maintenance afterwards to
remain cute.
Thanks,
Glen
--
View this message in context:
http://cxf.547215.n5.nabble.com/Apache-CXF-tooling-usage-definitions-tp3253466p3260484.html
Sent from the cxf-user mailing list archive at Nabble.com.
