David E Jones wrote:
> On Dec 21, 2009, at 2:04 AM, Adam Heath wrote:
> 
>> David E Jones wrote:
>>> On Dec 21, 2009, at 1:49 AM, Adam Heath wrote:
>>>
>>>> David E Jones wrote:
>>>>> On Dec 21, 2009, at 1:35 AM, Adam Heath wrote:
>>>>>
>>>>>> hans...@apache.org wrote:
>>>>>>> Author: hansbak
>>>>>>> Date: Mon Dec 21 07:31:58 2009
>>>>>>> New Revision: 892712
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewvc?rev=892712&view=rev
>>>>>>> Log:
>>>>>>> Upgrade Axis1 to Axis2. Ofbiz now supports complex parameters in 
>>>>>>> webservices including WSDL generation. see OFBIZ-3363 for more info. A 
>>>>>>> contribution of Antwebsystems employee Chatree
>>>>>>>
>>>>>>> Added:
>>>>>>>  ofbiz/trunk/framework/service/lib/XmlSchema-1.4.3.jar   (with props)
>>>>>>>  ofbiz/trunk/framework/service/lib/axiom-api-1.2.8.jar   (with props)
>>>>>>>  ofbiz/trunk/framework/service/lib/axiom-impl-1.2.8.jar   (with props)
>>>>>>>  ofbiz/trunk/framework/service/lib/axis2-kernel-1.5.1.jar   (with props)
>>>>>>>  ofbiz/trunk/framework/service/lib/axis2-transport-http-1.5.1.jar   
>>>>>>> (with props)
>>>>>>>  ofbiz/trunk/framework/service/lib/axis2-transport-local-1.5.1.jar   
>>>>>>> (with props)
>>>>>>>  ofbiz/trunk/framework/service/lib/commons-httpclient-3.1.jar   (with 
>>>>>>> props)
>>>>>>>  ofbiz/trunk/framework/service/lib/neethi-2.0.4.jar   (with props)
>>>>>>>  
>>>>>>> ofbiz/trunk/framework/service/src/org/ofbiz/service/test/ServiceSOAPTests.java
>>>>>>>    (with props)
>>>>>>> Modified:
>>>>>>>  ofbiz/trunk/LICENSE
>>>>>>>  ofbiz/trunk/framework/common/servicedef/services_test.xml
>>>>>>>  ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java
>>>>>>>  ofbiz/trunk/framework/service/src/org/ofbiz/service/ModelParam.java
>>>>>>>  ofbiz/trunk/framework/service/src/org/ofbiz/service/ModelService.java
>>>>>>>  
>>>>>>> ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/SOAPClientEngine.java
>>>>>>>  ofbiz/trunk/framework/service/testdef/servicetests.xml
>>>>>>>  
>>>>>>> ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/event/SOAPEventHandler.java
>>>>>> What about .classpath?
>>>>> What about it? We can't assume everyone uses Eclipse...
>>>> What does using eclipse have to do with updating that file?  I don't
>>>> use eclipse, but I still update .classpath.  I also don't use ant.bat,
>>>> yet I just updated that.
>>>>
>>>> If you know that you have to keep .classpath updated to make eclipse
>>>> work, and you knowingly check in new libraries, or remove old ones,
>>>> then why make eclipse broken?  It's really not that hard to change.
>>>>
>>>> Honestly, I don't understand why you would think not keeping it
>>>> uptodate is a good thing.
>>>>
>>>> ... perplexed ...
>>> Where did I write "not keeping it uptodate is a good thing?" And if I 
>>> didn't write it, how can you assert I was thinking it?
>> How else could what you wrote be interpreted?  Because you responded,
>> it seemed to imply that you disagreed that it wasn't important to keep
>> it uptodate.
>>
>> If you actually meant something else, then you should have said so.
>>
>> My 3 words meant that it should have been updated.  What did you
>> actually mean?
>>
>> I still can't see how your response could be interpreted in any other way.
>>
>> And I'm rather perplexed at having to explain my 3 simple words in
>> such detail, esp. to you, David.
> 
> What does it have to do with your 3 words?
> 
> What did I mean? I meant:
> 
> What about .classpath? If Hans doesn't use Eclipse, how can you expect him to
> keep that Eclipse-specific file updated, especially since it has been
> historically maintained by Eclipse users. Some things, like the
LICENSE and
> NOTICE files that Jacques pointed out, really are responsibilities
of committers.
> I wouldn't consider keeping the Eclipse .classpath file one of those
responsibilities.

We are all in this together.  The more people who keep an eye on the
various parts of the project, and the more people who keep things
working, the better.

There are some things that are *very* easy to check.  .classpath is
most definately one of those.  Keeping it in sync is so very very very
simple, why shouldn't it be kept in sync when library changes occur?

At what level should due diligence be thrown out the window?

When the default memory requirements for ofbiz change, should only the
shell scripts be changed, only the .bat files, or both?  What if new
system properties need to be set?  Should that only be done in one set
of files?

Or, for another example, what about keeping the embedded ant working,
vs. an external, system installed ant?

I completely understand how some people may not use some small part of
 ofbiz; there are so many parts, it can be hard to keep them all in
working order.  However, some of those small parts are at least easy
to work with, and simple enough to see obviously broken behaviour,
that updating them when other parts change is easy.

I really still can't believe that you are suggesting that keeping this
very simple to understand text file uptodate is not a worthwhile goal
for everyone.

> Is that clear enough?

Clear, yes.  However, it still doesn't make any sense to me.

> Shall I go on? Why are you trying to imply that Hans should do this, as if 
> he's
> made some sort of mistake and it's his responsibility to correct it?
Why didn't
> you just correct it yourself if you care so much about it? Who says the
> responsibility belongs to one more than another, and if it doesn't
why are you
> trying to get someone else to do something by implying it is their
responsibility
> instead of working with them in a more friendly and respectful way?

I didn't correct it myself, because more eyes/hands makes for a better
project.  The more people we have looking over the system, the better
the system will be.

Of course I could have correct this issue.  I could have even done it
silently.  But then no one would learn, and no one would become better.

Besides, the best practices for contributors(1) says: first, do no harm.

I can understand when mistakes get made.  We are all human, none of us
are perfect.  However, when a mistake is eventually made, if it is
never pointed out, how can you expect the person who made the mistake
to get better?  I don't point out issues to make people feel bad; I
point them out to make them better.

I've said this before, I don't consider the background of a person
when I read a commit message.  I just comment on that particular commit.

> Okay, I think that's about all I can figure out to say on this little topic...
> if you need more clarification and expansion I'll try to put
together a more
> general philosophical background. On the other hand, I've written a
few blog
> entries that are related to this and that I think explain it rather
well.

Which blog entries have you written?  Links would be nice.

1:
http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices


Reply via email to