Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

[David E. Jones-2]

This all reminds me of the ideas behind "Tragedy of the Commons":

http://en.wikipedia.org/wiki/Tragedy_of_the_commons

Software doesn't typically represent a limited resource that can be overused, so that's not what I mean. What I mean is the more general idea behind that of how people interact with shared resources and the effect on everyone's long-term interest in it. It's not a new pattern, but one we'll have to work around if the community and the software are to remain strong and viable.

-David


On Mar 6, 2010, at 7:43 AM, Scott Gray wrote:

> Your problem Hans, is that you spend too much time believing you are being personally attacked and not enough time dealing with the actual issues being discussed.  It always appears that your first response to any feedback is to attempt to ignore it, things then always end up escalating as they have done here.
>
> Personally, I've stopped reviewing most of your commits because you only ever saw it as a negative thing and I can't be bothered fighting with you.
>
> Regards
> Scott
>
> On 6/03/2010, at 2:55 AM, Hans Bakker wrote:
>
>> I give up already before your message, Tim.
>>
>> as happened often in the past as with the setup application, with the
>> myportal application, with the birt integration, with the new ebay
>> component and now with this twitter account, i get really tired by
>> certain people fighting, especially new, additions to the system. For
>> the good of the project? i am sorry i do not think so. Certain people
>> like to show their powers only. Read other mailinglists how other people
>> think about ofbiz and how many people are using ofbiz but do not
>> contribute.
>>
>> Discussion before hand? I think it gets then even more problematic, it
>> takes too long time, my customer does not want to wait for.
>>
>> I am now slowly considering creating components outside of ofbiz like is
>> happening in china and France because it is causing too much grief and
>> discussion to get it into ofbiz.
>>
>> Regards,
>> Hans
>>
>>
>>
>>
>> On Sat, 2010-03-06 at 01:48 -0700, Tim Ruppert wrote:
>>> Please send me the credentials as well - I'd like to update the Bio and make this actually look like an ASF resource if we're being forced into having something else to maintain.  We all have twitter feeds, but we didn't post them on the front page acting like they are coming from the project - this is the inherent problem.
>>>
>>> Btw, Hans, in the future, I would appreciate you talking BEFORE you starting making more things for the project to be in charge of - ebaystore, twitter account for the project, etc, etc.  I'm a willing participant, but just because you have commit privileges doesn't mean that you shouldn't have conversations about what you're doing and why.  I think that if you followed this guideline, and looked for some more help before diving on issues, you might find that there are plenty of people that are interested in your ideas and they might contribute to a higher quality product than you're tossing out by yourself (this is at least something I've always subscribed to).
>>>
>>> Just my two cents ....  I still think this commit should be reverted until we figure out a process and plan to support Twitter (if this indeed is something that the ASF allows and we are into supporting as a group).  Love the enthusiasm all around.
>>>
>>> Cheers,
>>> Ruppert
>>>
>>> On Mar 5, 2010, at 9:07 PM, Scott Gray wrote:
>>>
>>>> Ah I see, you really must send me a copy of the Hans Bakker rule book for use of the 'official' OFBiz twitter account.
>>>>
>>>> By the way, you offered to send the account credentials to any committers that requested it, please send me the credentials.
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> On 5/03/2010, at 8:33 PM, Hans Bakker wrote:
>>>>
>>>>> sure if you provide some tweets of your own...sorry only fighting a new
>>>>> feature is not rewarded.
>>>>>
>>>>> On Fri, 2010-03-05 at 20:11 -0700, Scott Gray wrote:
>>>>>> Thanks, while your at it you may as well spell Pranay's name correctly too.  
>>>>>>
>>>>>> And since I've now spent some time helping you with the feed, could you please add my name to the Bio section, I feel like I deserve some credit for it.
>>>>>>
>>>>>> Thanks
>>>>>> Scott
>>>>>>
>>>>>> On 5/03/2010, at 8:06 PM, Hans Bakker wrote:
>>>>>>
>>>>>>> Sure Scott, twitter has been changed.
>>>>>>>
>>>>>>> On Fri, 2010-03-05 at 19:37 -0700, Scott Gray wrote:
>>>>>>>> Here's an example of why the whole thing makes me uncomfortable:
>>>>>>>> Latest tweet from apache_ofbiz:
>>>>>>>> "Using Ajax in Ofbiz? Check part 6 in the ofbiz development tutorial guide at http://j.mp/bvTEwU . A pity it is not using forms.Thanks Praney"
>>>>>>>> The 3rd sentence is quite clearly an opinion and thus Hans' opinion is now the opinion of the project in the eyes of people reading these tweets.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 5/03/2010, at 7:31 PM, Scott Gray wrote:
>>>>>>>>
>>>>>>>>> The key point you are missing here Hans is that nobody asked you to provide this "service" to the community on behalf of the project and you have no right to do so.  You are very clearly violating the ASF's policies and I would ask you kindly to revert your revert of my revert.
>>>>>>>>>
>>>>>>>>> If you really believe that this is something that is wanted then request a vote on the PMC list and I will gladly accept the result.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 5/03/2010, at 7:13 PM, Hans Bakker wrote:
>>>>>>>>>
>>>>>>>>>> I answered all outstanding questions and concerns and consider these
>>>>>>>>>> issues resolved.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hans
>>>>>>>>>>
>>>>>>>>>> On Fri, 2010-03-05 at 19:03 -0700, Scott Gray wrote:
>>>>>>>>>>> Reverted in r919688, I am in no way comfortable with you running a twitter feed and pretending that it represents the OFBiz project regardless of your intentions.  If you want to do something like this then get it approved by the PMC first.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> On 5/03/2010, at 12:26 AM, Hans Bakker wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ok, here an answer for all the questions about this twitter account.
>>>>>>>>>>>>
>>>>>>>>>>>> First of all, as i already said, i was just making promotion for OFBiz,
>>>>>>>>>>>> to the casual end user who want to see what is happening and may later
>>>>>>>>>>>> get involved.
>>>>>>>>>>>> Do i do this for free? No, i want something back, only that
>>>>>>>>>>>> Antwebsystems is mentioned somewhere doing this service. As long as i do
>>>>>>>>>>>> it alone i think this is pretty reasonable.
>>>>>>>>>>>>
>>>>>>>>>>>> Is this an Antwebsystems account?
>>>>>>>>>>>> No it is not. The antwebsystems account is
>>>>>>>>>>>> http://twitter.com/ofbiz_support 
>>>>>>>>>>>> and my personal account is:
>>>>>>>>>>>> http://twitter.com/hansbak .
>>>>>>>>>>>>
>>>>>>>>>>>> If you go to http://antwebsystems.com you will see these tweets at the
>>>>>>>>>>>> right hand side of the website. I think this would also be nice for the
>>>>>>>>>>>> OFBiz website, of course the OFBiz account only :-)
>>>>>>>>>>>>
>>>>>>>>>>>> This is my contribution to the Apache OFBiz project. It has nothing to
>>>>>>>>>>>> do with the apache foundation, it is just OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> Will it be accessible to all contributors?
>>>>>>>>>>>> Sure, running a professional twitter account takes time and effort. Any
>>>>>>>>>>>> contributor interested helping here is very welcome, as long we keep the
>>>>>>>>>>>> target user in mind: the potential end user.
>>>>>>>>>>>>
>>>>>>>>>>>> Hopefully this clears up everything and we can return back to what we
>>>>>>>>>>>> are doing best: promote and improve OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Hans.
>>>>>>>>>>>>
>>>>>>>>>>>> P.S. If somebody is interested helping let me know i will give you
>>>>>>>>>>>> access if you are a committer. If you are a contributor send your tweets
>>>>>>>>>>>> to @apache_ofbiz and i will retweet them if they fit the target
>>>>>>>>>>>> audience.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>>>
>>>>>>
>>>>> --
>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>
>>>>
>>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>

[Ean Schuessler]

Hans Bakker wrote:

> I give up already before your message, Tim.
>
> as happened often in the past as with the setup application, with the
> myportal application, with the birt integration, with the new ebay
> component and now with this twitter account, i get really tired by
> certain people fighting, especially new, additions to the system. For
> the good of the project? i am sorry i do not think so. Certain people
> like to show their powers only. Read other mailinglists how other people
> think about ofbiz and how many people are using ofbiz but do not
> contribute.
>
> Discussion before hand? I think it gets then even more problematic, it
> takes too long time, my customer does not want to wait for.
>
> I am now slowly considering creating components outside of ofbiz like is
> happening in china and France because it is causing too much grief and
> discussion to get it into ofbiz.
>  

This message comments on the general state of affairs with Hans and not

just the effort to add a Twitterfeed in the vein of what other competing
projects already have on their home page.

Having spent the past month dealing with the sorry state of purchase
returns I do have to say that I feel an unfair standard is applied to
Hans'. The portal, the project manager, the Ebay integration and the
BIRT integration are, in my mind, some of the most interesting new
developments in the system and I am actively trying to figure out how to
put them to use. The Ebay system connects your lowly OFBiz inventory
into the world's largest marketplace and the BIRT integration adds (or
works towards adding) enterprise level reporting that is a silver bullet
item for us when presenting the system to clients.

Fundamentally,  I see a failure to honor the contribution in proportion
to complaining about its flaws. Its as if someone brought you a valuable
gift and all you could comment on is the quality of the wrapping paper.
We should work harder to assist in the integration of these useful tools
rather than turning on a "my way or the highway" flamethrower. (see
Matthew 7:3)

Hans' contributions have inarguable value and some of the weaknesses in
his commits (ie. inconsistent indentation) seem like a good opportunity
for someone with less experience to do something useful. It would be a
crying shame if we lost the features I listed above because of otherwise
minor imperfections in their construction.
> On Sat, 2010-03-06 at 01:48 -0700, Tim Ruppert wrote:
>  
>> Please send me the credentials as well - I'd like to update the Bio and make this actually look like an ASF resource if we're being forced into having something else to maintain.  We all have twitter feeds, but we didn't post them on the front page acting like they are coming from the project - this is the inherent problem.
>>
>> Btw, Hans, in the future, I would appreciate you talking BEFORE you starting making more things for the project to be in charge of - ebaystore, twitter account for the project, etc, etc.  I'm a willing participant, but just because you have commit privileges doesn't mean that you shouldn't have conversations about what you're doing and why.  I think that if you followed this guideline, and looked for some more help before diving on issues, you might find that there are plenty of people that are interested in your ideas and they might contribute to a higher quality product than you're tossing out by yourself (this is at least something I've always subscribed to).
>>    

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Tim Ruppert]

Still looking forward to discussing and rectifying how we have two ebay stores and how that's just something I'm supposed to be happy about - even if it could be a job for someone who's not as gifted.  This has ZERO to do with Hans - that's the problem - the victim role just doesn't work around here.  It has everything to do with the fact that rules were broken, discussion is overlooked or ignored, and we have massive amounts of duplication because of this - all the while hiding behind being "attacked" instead of focusing on what is being asked by the person reporting the issues.

If there are others that you feel are not being held to the same standard that Hans is, then what I would suggest is to start to hold people to that standard instead of lowering the level of quality that we need to achieve.  This may be a community project, but we're not all hippies here - we need to be accountable for what we do and work towards doing a much better job - and that goes for each every one of us.

Feel free to burn me at the stake if I introduce another component without taking the time to do proper analysis of what is currently out there - and especially if I blow off the discussion the way that we see regularly. Anyways, I want to make it clear that I'm not here to start anything else up - I've got nothing against Hans in ANY way - I just respectfully disagree with the Zen you are experiencing at the moment with the way the contributions are made.

That being said, Hans has made great contributions over the past year - and I do not mean to take anything away from the end result - the road was definitely sometimes difficult and I'm glad that we're thru most of it.  Kudos to Hans - and peace man peace.  Looking forward to seeing more people looking at the code and hopefully improving what everyone is producing.

Cheers,
Ruppert

On Mar 10, 2010, at 5:25 PM, Ean Schuessler wrote:

> Hans Bakker wrote:
>> I give up already before your message, Tim.
>>
>> as happened often in the past as with the setup application, with the
>> myportal application, with the birt integration, with the new ebay
>> component and now with this twitter account, i get really tired by
>> certain people fighting, especially new, additions to the system. For
>> the good of the project? i am sorry i do not think so. Certain people
>> like to show their powers only. Read other mailinglists how other people
>> think about ofbiz and how many people are using ofbiz but do not
>> contribute.
>>
>> Discussion before hand? I think it gets then even more problematic, it
>> takes too long time, my customer does not want to wait for.
>>
>> I am now slowly considering creating components outside of ofbiz like is
>> happening in china and France because it is causing too much grief and
>> discussion to get it into ofbiz.
>>  
> This message comments on the general state of affairs with Hans and not just the effort to add a Twitterfeed in the vein of what other competing projects already have on their home page.
>
> Having spent the past month dealing with the sorry state of purchase returns I do have to say that I feel an unfair standard is applied to Hans'. The portal, the project manager, the Ebay integration and the BIRT integration are, in my mind, some of the most interesting new developments in the system and I am actively trying to figure out how to put them to use. The Ebay system connects your lowly OFBiz inventory into the world's largest marketplace and the BIRT integration adds (or works towards adding) enterprise level reporting that is a silver bullet item for us when presenting the system to clients.
>
> Fundamentally,  I see a failure to honor the contribution in proportion to complaining about its flaws. Its as if someone brought you a valuable gift and all you could comment on is the quality of the wrapping paper. We should work harder to assist in the integration of these useful tools rather than turning on a "my way or the highway" flamethrower. (see Matthew 7:3)
>
> Hans' contributions have inarguable value and some of the weaknesses in his commits (ie. inconsistent indentation) seem like a good opportunity for someone with less experience to do something useful. It would be a crying shame if we lost the features I listed above because of otherwise minor imperfections in their construction.
>> On Sat, 2010-03-06 at 01:48 -0700, Tim Ruppert wrote:
>>  
>>> Please send me the credentials as well - I'd like to update the Bio and make this actually look like an ASF resource if we're being forced into having something else to maintain.  We all have twitter feeds, but we didn't post them on the front page acting like they are coming from the project - this is the inherent problem.
>>>
>>> Btw, Hans, in the future, I would appreciate you talking BEFORE you starting making more things for the project to be in charge of - ebaystore, twitter account for the project, etc, etc.  I'm a willing participant, but just because you have commit privileges doesn't mean that you shouldn't have conversations about what you're doing and why.  I think that if you followed this guideline, and looked for some more help before diving on issues, you might find that there are plenty of people that are interested in your ideas and they might contribute to a higher quality product than you're tossing out by yourself (this is at least something I've always subscribed to).
>>>    
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[Scott Gray-2]

On 10/03/2010, at 5:25 PM, Ean Schuessler wrote:

> Hans Bakker wrote:
>> I give up already before your message, Tim.
>>
>> as happened often in the past as with the setup application, with the
>> myportal application, with the birt integration, with the new ebay
>> component and now with this twitter account, i get really tired by
>> certain people fighting, especially new, additions to the system. For
>> the good of the project? i am sorry i do not think so. Certain people
>> like to show their powers only. Read other mailinglists how other people
>> think about ofbiz and how many people are using ofbiz but do not
>> contribute.
>>
>> Discussion before hand? I think it gets then even more problematic, it
>> takes too long time, my customer does not want to wait for.
>>
>> I am now slowly considering creating components outside of ofbiz like is
>> happening in china and France because it is causing too much grief and
>> discussion to get it into ofbiz.
>>  
> This message comments on the general state of affairs with Hans and not just the effort to add a Twitterfeed in the vein of what other competing projects already have on their home page.
>
> Having spent the past month dealing with the sorry state of purchase returns I do have to say that I feel an unfair standard is applied to Hans'.
> The portal,

No one complained about portal, there was a lot of collaboration around it.

> the project manager,

The only issues I'm aware of have been changes causing the underlying applications to break, I'm not sure how no one could complain about that if it directly effects them.

> the Ebay integration

The problem here was with having two competing special applications, redundant code and diverging feature sets.  No one is against new eBay integration features.

> and the BIRT integration are

I'm not aware of anyone being against the birt integration, there were simply licensing issues which needed to be addressed.  I'm glad it made it in and look forward to contributing to it at some point.

> , in my mind, some of the most interesting new developments in the system and I am actively trying to figure out how to put them to use. The Ebay system connects your lowly OFBiz inventory into the world's largest marketplace and the BIRT integration adds (or works towards adding) enterprise level reporting that is a silver bullet item for us when presenting the system to clients.
>
> Fundamentally,  I see a failure to honor the contribution in proportion to complaining about its flaws. Its as if someone brought you a valuable gift and all you could comment on is the quality of the wrapping paper. We should work harder to assist in the integration of these useful tools rather than turning on a "my way or the highway" flamethrower. (see Matthew 7:3)

The issues I mention above can hardly be considered wrapping paper, and "complaining" is the wrong word, what is being provided is feedback and that feedback is being treated as some sort of attack.  There is no "my way or the highway" flamethrower, there are only discussions about what is good for the project going forward.

> Hans' contributions have inarguable value and some of the weaknesses in his commits (ie. inconsistent indentation) seem like a good opportunity for someone with less experience to do something useful. It would be a crying shame if we lost the features I listed above because of otherwise minor imperfections in their construction.

Quite often there is no time to do an in-depth analysis of commits and IMO sloppy formatting can be indicative of sloppy code and mentioning them keeps the contributor aware that people are watching and perhaps encourages to take more care in what they are writing.  If a committer takes offense at being pulled up on poor formatting then tough luck, if anyone else commits something similar they'll get the same response so there is no inequality here.

In the years that I've worked on OFBiz I've contributed hundreds if not thousands of unpaid hours, do I ask for thanks? No.  Do I feel bad when someone pulls up one of my commits? No, I'm happy for it and wish it would happen more.  I'm sorry that Hans feels attacked every time I start up a discussion with him, but the "attack" is in his perception and there is nothing I can do about that.  I'm not here to make Hans feel good about his contributions nor am I here to make him feel bad, I'm just here to talk about code and about the project.

>> On Sat, 2010-03-06 at 01:48 -0700, Tim Ruppert wrote:
>>  
>>> Please send me the credentials as well - I'd like to update the Bio and make this actually look like an ASF resource if we're being forced into having something else to maintain.  We all have twitter feeds, but we didn't post them on the front page acting like they are coming from the project - this is the inherent problem.
>>>
>>> Btw, Hans, in the future, I would appreciate you talking BEFORE you starting making more things for the project to be in charge of - ebaystore, twitter account for the project, etc, etc.  I'm a willing participant, but just because you have commit privileges doesn't mean that you shouldn't have conversations about what you're doing and why.  I think that if you followed this guideline, and looked for some more help before diving on issues, you might find that there are plenty of people that are interested in your ideas and they might contribute to a higher quality product than you're tossing out by yourself (this is at least something I've always subscribed to).
>>>    
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[David E. Jones-2]

Oh yeah, I'm "feeling the love" now "my friend."

After reading enough similar comments from a number of people in recent weeks I think I'm starting to come around to a different way of looking at things, and I think I know how to fix all of these community problems with people not getting along and the software quality falling well below industry standards.

We don't want a community where contributions are appreciated and issues with contributions are met in-kind with additional contributions that help fix the problems. We don't want to appreciate what is contributed except in passing here and there in order to look like nice people, quite frankly, most of it's crap anyway and that fact that this stuff continually fails to meet my needs actually causes me a lot of pain.

To sum it up what we want is: more critics and less contributors. We want more accountability and less collaboration (which is way overrated).

We want contributors to understand that if they contribute something they better darn well be prepared to do a few things, including:

1. support it: fix any problem ever found in it or related to it at any point in the future (even years later), and answer questions about it as they arise (also in perpetuity)

2. market it: convince others in the community that it's of value to them, and if they don't see why it's of value then discuss it and push it as long as necessary (and don't give up because then you'll be seen as weak or a victim and the jackals will be all over that)

3. document it: in a clear and organized way write about what it does, how it does it, every way it could possibly be used, and everything that might go wrong when using it or customizing it

4. test it (automated): if there are no automated tests then it can't possibly work, and you're not going to convince anyone that it does; maybe just as important is that you need automated tests for every possible way of using it because what if someone wants to use it in a way you didn't plan for it to be used and it doesn't work for them?

If you don't do all these things you aren't good enough to be an OFBiz contributor (and your probably not very smart, skilled, careful, or dedicated either), and it would be better for your to join the critics (the peanut gallery), or even better just go elsewhere and stop bothering those of us who really make this project what it is.

For my part I prefer to play it safe and just not contribute much (if anything). I'm fine with offering to allow others to burn me at the stake should I mess up because I have no intention of ever contributing anything that could possibly not be perfect and complete. That's right, safely in the peanut gallery and telling others what to do (or not to do) is the life for me. While on the topic, I want to say again that I really don't appreciate all of the crap that is contributed that forces me into this position. I don't like being the bad guy, but everyone who contributes here is so incompetent that someone's got to do it or this project will just fall apart.

-Not David


On Mar 10, 2010, at 5:44 PM, Tim Ruppert wrote:

> Still looking forward to discussing and rectifying how we have two ebay stores and how that's just something I'm supposed to be happy about - even if it could be a job for someone who's not as gifted.  This has ZERO to do with Hans - that's the problem - the victim role just doesn't work around here.  It has everything to do with the fact that rules were broken, discussion is overlooked or ignored, and we have massive amounts of duplication because of this - all the while hiding behind being "attacked" instead of focusing on what is being asked by the person reporting the issues.
>
> If there are others that you feel are not being held to the same standard that Hans is, then what I would suggest is to start to hold people to that standard instead of lowering the level of quality that we need to achieve.  This may be a community project, but we're not all hippies here - we need to be accountable for what we do and work towards doing a much better job - and that goes for each every one of us.
>
> Feel free to burn me at the stake if I introduce another component without taking the time to do proper analysis of what is currently out there - and especially if I blow off the discussion the way that we see regularly. Anyways, I want to make it clear that I'm not here to start anything else up - I've got nothing against Hans in ANY way - I just respectfully disagree with the Zen you are experiencing at the moment with the way the contributions are made.
>
> That being said, Hans has made great contributions over the past year - and I do not mean to take anything away from the end result - the road was definitely sometimes difficult and I'm glad that we're thru most of it.  Kudos to Hans - and peace man peace.  Looking forward to seeing more people looking at the code and hopefully improving what everyone is producing.
>
> Cheers,
> Ruppert
>
> On Mar 10, 2010, at 5:25 PM, Ean Schuessler wrote:
>
>> Hans Bakker wrote:
>>> I give up already before your message, Tim.
>>>
>>> as happened often in the past as with the setup application, with the
>>> myportal application, with the birt integration, with the new ebay
>>> component and now with this twitter account, i get really tired by
>>> certain people fighting, especially new, additions to the system. For
>>> the good of the project? i am sorry i do not think so. Certain people
>>> like to show their powers only. Read other mailinglists how other people
>>> think about ofbiz and how many people are using ofbiz but do not
>>> contribute.
>>>
>>> Discussion before hand? I think it gets then even more problematic, it
>>> takes too long time, my customer does not want to wait for.
>>>
>>> I am now slowly considering creating components outside of ofbiz like is
>>> happening in china and France because it is causing too much grief and
>>> discussion to get it into ofbiz.
>>>
>> This message comments on the general state of affairs with Hans and not just the effort to add a Twitterfeed in the vein of what other competing projects already have on their home page.
>>
>> Having spent the past month dealing with the sorry state of purchase returns I do have to say that I feel an unfair standard is applied to Hans'. The portal, the project manager, the Ebay integration and the BIRT integration are, in my mind, some of the most interesting new developments in the system and I am actively trying to figure out how to put them to use. The Ebay system connects your lowly OFBiz inventory into the world's largest marketplace and the BIRT integration adds (or works towards adding) enterprise level reporting that is a silver bullet item for us when presenting the system to clients.
>>
>> Fundamentally,  I see a failure to honor the contribution in proportion to complaining about its flaws. Its as if someone brought you a valuable gift and all you could comment on is the quality of the wrapping paper. We should work harder to assist in the integration of these useful tools rather than turning on a "my way or the highway" flamethrower. (see Matthew 7:3)
>>
>> Hans' contributions have inarguable value and some of the weaknesses in his commits (ie. inconsistent indentation) seem like a good opportunity for someone with less experience to do something useful. It would be a crying shame if we lost the features I listed above because of otherwise minor imperfections in their construction.
>>> On Sat, 2010-03-06 at 01:48 -0700, Tim Ruppert wrote:
>>>
>>>> Please send me the credentials as well - I'd like to update the Bio and make this actually look like an ASF resource if we're being forced into having something else to maintain.  We all have twitter feeds, but we didn't post them on the front page acting like they are coming from the project - this is the inherent problem.
>>>>
>>>> Btw, Hans, in the future, I would appreciate you talking BEFORE you starting making more things for the project to be in charge of - ebaystore, twitter account for the project, etc, etc.  I'm a willing participant, but just because you have commit privileges doesn't mean that you shouldn't have conversations about what you're doing and why.  I think that if you followed this guideline, and looked for some more help before diving on issues, you might find that there are plenty of people that are interested in your ideas and they might contribute to a higher quality product than you're tossing out by yourself (this is at least something I've always subscribed to).
>>>>
>>
>> --
>> Ean Schuessler, CTO
>> [hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>
>

[Tim Ruppert]

Hans, whenever you're ready, I'd still love to talk to you about how we can help to merge the two ebay components together.  Let me know.

Cheers,
Ruppert

On Mar 10, 2010, at 11:30 PM, David E Jones wrote:

>
> Oh yeah, I'm "feeling the love" now "my friend."
>
> After reading enough similar comments from a number of people in recent weeks I think I'm starting to come around to a different way of looking at things, and I think I know how to fix all of these community problems with people not getting along and the software quality falling well below industry standards.
>
> We don't want a community where contributions are appreciated and issues with contributions are met in-kind with additional contributions that help fix the problems. We don't want to appreciate what is contributed except in passing here and there in order to look like nice people, quite frankly, most of it's crap anyway and that fact that this stuff continually fails to meet my needs actually causes me a lot of pain.
>
> To sum it up what we want is: more critics and less contributors. We want more accountability and less collaboration (which is way overrated).
>
> We want contributors to understand that if they contribute something they better darn well be prepared to do a few things, including:
>
> 1. support it: fix any problem ever found in it or related to it at any point in the future (even years later), and answer questions about it as they arise (also in perpetuity)
>
> 2. market it: convince others in the community that it's of value to them, and if they don't see why it's of value then discuss it and push it as long as necessary (and don't give up because then you'll be seen as weak or a victim and the jackals will be all over that)
>
> 3. document it: in a clear and organized way write about what it does, how it does it, every way it could possibly be used, and everything that might go wrong when using it or customizing it
>
> 4. test it (automated): if there are no automated tests then it can't possibly work, and you're not going to convince anyone that it does; maybe just as important is that you need automated tests for every possible way of using it because what if someone wants to use it in a way you didn't plan for it to be used and it doesn't work for them?
>
> If you don't do all these things you aren't good enough to be an OFBiz contributor (and your probably not very smart, skilled, careful, or dedicated either), and it would be better for your to join the critics (the peanut gallery), or even better just go elsewhere and stop bothering those of us who really make this project what it is.
>
> For my part I prefer to play it safe and just not contribute much (if anything). I'm fine with offering to allow others to burn me at the stake should I mess up because I have no intention of ever contributing anything that could possibly not be perfect and complete. That's right, safely in the peanut gallery and telling others what to do (or not to do) is the life for me. While on the topic, I want to say again that I really don't appreciate all of the crap that is contributed that forces me into this position. I don't like being the bad guy, but everyone who contributes here is so incompetent that someone's got to do it or this project will just fall apart.
>
> -Not David
>
>
> On Mar 10, 2010, at 5:44 PM, Tim Ruppert wrote:
>
>> Still looking forward to discussing and rectifying how we have two ebay stores and how that's just something I'm supposed to be happy about - even if it could be a job for someone who's not as gifted.  This has ZERO to do with Hans - that's the problem - the victim role just doesn't work around here.  It has everything to do with the fact that rules were broken, discussion is overlooked or ignored, and we have massive amounts of duplication because of this - all the while hiding behind being "attacked" instead of focusing on what is being asked by the person reporting the issues.
>>
>> If there are others that you feel are not being held to the same standard that Hans is, then what I would suggest is to start to hold people to that standard instead of lowering the level of quality that we need to achieve.  This may be a community project, but we're not all hippies here - we need to be accountable for what we do and work towards doing a much better job - and that goes for each every one of us.
>>
>> Feel free to burn me at the stake if I introduce another component without taking the time to do proper analysis of what is currently out there - and especially if I blow off the discussion the way that we see regularly. Anyways, I want to make it clear that I'm not here to start anything else up - I've got nothing against Hans in ANY way - I just respectfully disagree with the Zen you are experiencing at the moment with the way the contributions are made.
>>
>> That being said, Hans has made great contributions over the past year - and I do not mean to take anything away from the end result - the road was definitely sometimes difficult and I'm glad that we're thru most of it.  Kudos to Hans - and peace man peace.  Looking forward to seeing more people looking at the code and hopefully improving what everyone is producing.
>>
>> Cheers,
>> Ruppert
>>
>> On Mar 10, 2010, at 5:25 PM, Ean Schuessler wrote:
>>
>>> Hans Bakker wrote:
>>>> I give up already before your message, Tim.
>>>>
>>>> as happened often in the past as with the setup application, with the
>>>> myportal application, with the birt integration, with the new ebay
>>>> component and now with this twitter account, i get really tired by
>>>> certain people fighting, especially new, additions to the system. For
>>>> the good of the project? i am sorry i do not think so. Certain people
>>>> like to show their powers only. Read other mailinglists how other people
>>>> think about ofbiz and how many people are using ofbiz but do not
>>>> contribute.
>>>>
>>>> Discussion before hand? I think it gets then even more problematic, it
>>>> takes too long time, my customer does not want to wait for.
>>>>
>>>> I am now slowly considering creating components outside of ofbiz like is
>>>> happening in china and France because it is causing too much grief and
>>>> discussion to get it into ofbiz.
>>>>
>>> This message comments on the general state of affairs with Hans and not just the effort to add a Twitterfeed in the vein of what other competing projects already have on their home page.
>>>
>>> Having spent the past month dealing with the sorry state of purchase returns I do have to say that I feel an unfair standard is applied to Hans'. The portal, the project manager, the Ebay integration and the BIRT integration are, in my mind, some of the most interesting new developments in the system and I am actively trying to figure out how to put them to use. The Ebay system connects your lowly OFBiz inventory into the world's largest marketplace and the BIRT integration adds (or works towards adding) enterprise level reporting that is a silver bullet item for us when presenting the system to clients.
>>>
>>> Fundamentally,  I see a failure to honor the contribution in proportion to complaining about its flaws. Its as if someone brought you a valuable gift and all you could comment on is the quality of the wrapping paper. We should work harder to assist in the integration of these useful tools rather than turning on a "my way or the highway" flamethrower. (see Matthew 7:3)
>>>
>>> Hans' contributions have inarguable value and some of the weaknesses in his commits (ie. inconsistent indentation) seem like a good opportunity for someone with less experience to do something useful. It would be a crying shame if we lost the features I listed above because of otherwise minor imperfections in their construction.
>>>> On Sat, 2010-03-06 at 01:48 -0700, Tim Ruppert wrote:
>>>>
>>>>> Please send me the credentials as well - I'd like to update the Bio and make this actually look like an ASF resource if we're being forced into having something else to maintain.  We all have twitter feeds, but we didn't post them on the front page acting like they are coming from the project - this is the inherent problem.
>>>>>
>>>>> Btw, Hans, in the future, I would appreciate you talking BEFORE you starting making more things for the project to be in charge of - ebaystore, twitter account for the project, etc, etc.  I'm a willing participant, but just because you have commit privileges doesn't mean that you shouldn't have conversations about what you're doing and why.  I think that if you followed this guideline, and looked for some more help before diving on issues, you might find that there are plenty of people that are interested in your ideas and they might contribute to a higher quality product than you're tossing out by yourself (this is at least something I've always subscribed to).
>>>>>
>>>
>>> --
>>> Ean Schuessler, CTO
>>> [hidden email]
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>> http://www.brainfood.com
>>>
>>
>

[Adam Heath-2]

David E Jones wrote:
> [snip]

You know, I was going to start a thread like this, but you beat me to
it.  I actually have a concrete example of a major problem, so I'm
going to chime in.

As many are aware, I have been going thru adding many test cases to
lots of low-level utility code.  *Every* time I have done so, I have
*always* found a problem.  Without fail.

It's not that A with B with C with D fails.  It's that A and B and C
and D have issues all by themselves.  I consider this extremely
unacceptable.

The latest problem I have is quite the complex.  It's the
DelegatorFactory change.  It's very broken.  The original code only
existed in GenericDelegator.getGenericDelegator().  It would check a
local map, looking for an already constructed delegator, returning
*very* fast if one existed.

However, the new code inverts this.  Instead, DelegatorFactory calls
directly into UtilObject.getObjectFromFactory.  No caching at all.
The caching is deferred to DelegatorFactoryImpl.  So far, things seem
perfectly fine.

However, there are parts of ofbiz that don't store delegator
instances.  Instead, they store only the delegatorName.
org.ofbiz.entity.cache.AbstractCache is one of these.  It calls
DelegatorFactory.getDelegator every time it needs the actual delegator
instance.

So, with this long explanation, I still haven't shown any problem.
But just wait.

ServiceLoader, which is used by getObjectFromFactory, will walk the
*entire* classpath, each and every time it is called.

Again, still no exact problem.  But those who have been following may
be starting to see the trees thru this forest.

I had an importer written for a client, to convert a legacy database
to ofbiz schema.  On our internal ofbiz package based on 811524, this
importer ran in 15 minutes.  However, when I upgrade to 902021, I
didn't do a full db drop, and reimport.  When I did so today, I had to
kill the importer after running for 2 hours, with no end in site.

This was due to the entity cache for ProductAssoc getting large, and
creation of new ProductAssoc, which was causing the AbstractCache to
try and load delegator instances, which was then going thru the entire
classpath.  This completely fell over.

This slowdown is completely unacceptable.

However, even once identified, the problem is not straight forward.
Caching at a higher level, in DelegatorFactory.getDelegator, is not
correct either.

Moving the caching higher implies that the constructed delegator won't
be saved until it is completely done being constructed.  However,
during construction, the delegator creates several helper entities.
These include EntityCrypto, and the cache support classes.  These
classes also still have the same problem of not storing delegator
instances, instead just storing a name.  So, they try to load a
delegator with the correct name, and don't find it, because the
original delegator is not done being constructed.

But, we still aren't done with this particular problem.

When GenericPK and GenericValue get created, they try to set their
fields.  Setting any field on a GenericEntity requires that it knows
it's delegator.  However, creation doesn't actually set the delegator.
 Even the delegator name is null.  So any GenericEntity created during
delegator instantiation ends up trying to load a delegator named
"default", *not* with whatever delegator is actually being created.

There are a whole series of changes done over the years that have
caused these cascading problems.  And this problem is just one that I
have personally seen that has caused me to worry greatly.

What I am about to propose may sound rather severe, but I would like
to see a moratorium on any new features.  Test cases and bug fixes
only.  Ofbiz has gotten *WAY* *TOO* BUGGY*.

ps: I'm well on the way to fixing this huge delegator problem, and
should have it ready tomorrow.

[Jacopo Cappellato-4]

On Mar 11, 2010, at 8:14 AM, Adam Heath wrote:

> What I am about to propose may sound rather severe, but I would like
> to see a moratorium on any new features.  Test cases and bug fixes
> only.  Ofbiz has gotten *WAY* *TOO* BUGGY*.

Very interesting Adam. I may be wrong but I am under the impression that you have missed some of the irony in David's words.

Kind regards,

Jacopo

[Adam Heath-2]

Jacopo Cappellato wrote:
> On Mar 11, 2010, at 8:14 AM, Adam Heath wrote:
>
>> What I am about to propose may sound rather severe, but I would like
>> to see a moratorium on any new features.  Test cases and bug fixes
>> only.  Ofbiz has gotten *WAY* *TOO* BUGGY*.
>
> Very interesting Adam. I may be wrong but I am under the impression that you have missed some of the irony in David's words.

Oh, I saw the irony.  I just gave a more concrete example of a real,
very critical problem.

There are lots of new people who've come on board since the last time
I was involved with ofbiz, and the quality of the project has gone
down hill.

I can give you a list a mile long of problems with ofbiz, if you want
it.  Usability issues.  Unimplemented features.  Half-finished code.
Things all over.  It's like people who are writing code aren't even
using what they are writing.

For years, we at brainfood didn't fully use ofbiz.  We used the
delegator to manage the database, and did the very basic party
management stuff, but had managed to stay out of any other framework
or applications; we just hadn't needed them yet.

However, now that we are digging into the other parts of ofbiz, we are
finding problems all over the board, with things that have existed for
ages.  This troubles us deeply.

[David E. Jones-2]

On Mar 11, 2010, at 12:28 AM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> On Mar 11, 2010, at 8:14 AM, Adam Heath wrote:
>>
>>> What I am about to propose may sound rather severe, but I would like
>>> to see a moratorium on any new features.  Test cases and bug fixes
>>> only.  Ofbiz has gotten *WAY* *TOO* BUGGY*.
>>
>> Very interesting Adam. I may be wrong but I am under the impression that you have missed some of the irony in David's words.
>
> Oh, I saw the irony.  I just gave a more concrete example of a real,
> very critical problem.
>
> There are lots of new people who've come on board since the last time
> I was involved with ofbiz, and the quality of the project has gone
> down hill.

You're right Adam, this is a great example of a part of the project that has wandered a lot with lots of "cooks in the kitchen" and many changes are made without really understanding what is going on or what side-effects might arise.

Thank you for taking this approach to these issues. This is the best sort of contribution when issues are found, and a nice way to collaborate by respecting changes from others but also pitching in to help fix things.

From a bigger picture perspective... what are other ways we could handle this better?

On a historical note, this is the very reason why I pushed originally to have a very limited set of committers with write access to the framework. Later on this group grew to include all PMC members (a mistake IMO) and now includes all committers (I was okay with it at the time, and even though this was recent I also consider this a mistake).

Things are just too complicated for casual changes to have a good chance of working well. Or, that's my opinion anyway. What might be nice is to restrict access to the framework, and maybe even have people acting as moderators for different parts of the framework. For example, if you can't make any changes to the Entity Engine without going through Adam Heath then this may slow things down a bit, but there would be a review of the design and implementation of every new feature or fix and that would lead to more consistency and quality in the design and implementation of the tool, making it hopefully easier to use and safer to rely on.

That's not exactly in the spirit of open community, but maybe it's a better way to go?

-David

[Jacopo Cappellato-4]

On Mar 11, 2010, at 8:56 AM, David E Jones wrote:

>
> On Mar 11, 2010, at 12:28 AM, Adam Heath wrote:
>
>> Jacopo Cappellato wrote:
>>> On Mar 11, 2010, at 8:14 AM, Adam Heath wrote:
>>>
>>>> What I am about to propose may sound rather severe, but I would like
>>>> to see a moratorium on any new features.  Test cases and bug fixes
>>>> only.  Ofbiz has gotten *WAY* *TOO* BUGGY*.
>>>
>>> Very interesting Adam. I may be wrong but I am under the impression that you have missed some of the irony in David's words.
>>
>> Oh, I saw the irony.  I just gave a more concrete example of a real,
>> very critical problem.
>>
>> There are lots of new people who've come on board since the last time
>> I was involved with ofbiz, and the quality of the project has gone
>> down hill.
>
> You're right Adam, this is a great example of a part of the project that has wandered a lot with lots of "cooks in the kitchen" and many changes are made without really understanding what is going on or what side-effects might arise.
>
> Thank you for taking this approach to these issues. This is the best sort of contribution when issues are found, and a nice way to collaborate by respecting changes from others but also pitching in to help fix things.
>
> From a bigger picture perspective... what are other ways we could handle this better?
>
> On a historical note, this is the very reason why I pushed originally to have a very limited set of committers with write access to the framework. Later on this group grew to include all PMC members (a mistake IMO) and now includes all committers (I was okay with it at the time, and even though this was recent I also consider this a mistake).
>
> Things are just too complicated for casual changes to have a good chance of working well. Or, that's my opinion anyway. What might be nice is to restrict access to the framework, and maybe even have people acting as moderators for different parts of the framework. For example, if you can't make any changes to the Entity Engine without going through Adam Heath then this may slow things down a bit, but there would be a review of the design and implementation of every new feature or fix and that would lead to more consistency and quality in the design and implementation of the tool, making it hopefully easier to use and safer to rely on.
>
> That's not exactly in the spirit of open community, but maybe it's a better way to go?
>
> -David
>

David,

thanks for sharing your thoughts about our strategy about committers and commit rights.
If we are not happy about the results of our last resolutions we can review and rethink it, I am wide open to discuss this.
We actually may want to explore the following strategy:
1) do not change commit rights but
2) define some sort of hierarchy where "junior" committers are assigned to "senior" committers that are responsible for validating the work they do in specific areas

Kind regards,

Jacopo

[Adam Heath-2]

Adam Heath wrote:
> I can give you a list a mile long of problems with ofbiz, if you want
> it.  Usability issues.  Unimplemented features.  Half-finished code.
> Things all over.  It's like people who are writing code aren't even
> using what they are writing.

(replying to myself, with a few more examples)

JobSandbox is stupid.  We at brainfood hate it.  Very much.  It craps
out when there are problems.

Let's say I'm trying to make gift certificate purchases work thru a
new web frontend.  As I'm doing this, I am doing things wrong.  Ok,
fine, I can accept that, I'm learning.  But, during this process, when
I attempt to convert a ShoppingCart to a real order, ofbGcPurchase is
called asynchronously.  This is part of the digital good fulfillment
process.  Still no problem.  But, because of a bug in my code, there
was no associated SurveyResponse to this OrderItem for the gift
certificate.  So, the ofbGcPurchase that was run asynchronously, and
stored in the JobSandbox fails.  Still no problem, really.

However, this JobSandbox entry runs over and over and over, without
ever stopping, and without any hope of ever finishing.  It should
*not* continue to retry.  Period.  This causes excess load.  Even more
so when tons of things fail, and they keep getting retried.

When cron in unix runs a job, and it fails, it doesn't keep retrying it.

Additionally, when a service requires a UserLogin object, and it is
scheduled to run in the future, but then the user changes their
password, the service will never succeed.  The only real way to fix
this is to *not* store the authentication principals in the context,
but store them in a separate location, kinda out-of-band(we could
still make use of an xml serializer when storing them into the database).

[Adrian Crum]

Adam Heath wrote:

> Moving the caching higher implies that the constructed delegator won't
> be saved until it is completely done being constructed.  However,
> during construction, the delegator creates several helper entities.
> These include EntityCrypto, and the cache support classes.  These
> classes also still have the same problem of not storing delegator
> instances, instead just storing a name.  So, they try to load a
> delegator with the correct name, and don't find it, because the
> original delegator is not done being constructed.
>
> But, we still aren't done with this particular problem.
>
> When GenericPK and GenericValue get created, they try to set their
> fields.  Setting any field on a GenericEntity requires that it knows
> it's delegator.  However, creation doesn't actually set the delegator.
>  Even the delegator name is null.  So any GenericEntity created during
> delegator instantiation ends up trying to load a delegator named
> "default", *not* with whatever delegator is actually being created.

I ran into that circular logic problem in the ExecutionContext branch. I
agree - there are a lot of problems with the delegator implementation
and they should be fixed. Let me know if there is anything I can do to help.

[Ean Schuessler]

----- "Jacopo Cappellato" wrote:
> thanks for sharing your thoughts about our strategy about committers and commit rights.
> If we are not happy about the results of our last resolutions we can review and rethink it, I am wide open to discuss this.
> We actually may want to explore the following strategy:
> 1) do not change commit rights but
> 2) define some sort of hierarchy where "junior" committers are assigned to "senior" committers that are responsible for validating the work they do in specific areas

This is exactly the way things are handled in the Linux kernel and exactly why Adam and I have been excitedly calling out "use GIT, use GIT!". The kernel team long ago ran into the problems of scaling control with the size of the contributing community. Originally they handled everything as a bunch of shell scripts that glued a workflow together out of tar balls and patchsets. Eventually that gave way to BitKeeper, which was up to the task but crippled by its proprietary nature. That lead to GIT.

In my mind, we should clone the Linux source management model because what we are running into is already a solved problem for them. There should be a very limited (perhaps even 1 or 2) number of people who commit directly to the SVN repository and those 1 or 2 people should be primarily focused on architecture and style rather than developing new features. Under this model, a commit process might look like this:

(Advance warning: there are mild comedic elements in this exchange. Adjust mental tone to "positive".)

- Hans: I've just radically expanded the ProjectManager to automatically synchronize itself with todo-items on BaseCamp, JIRA, DebBugs, Bugzilla and LaunchPad.
- David: Wow, that's interesting, let me take a look at that. (pulls a copy of Hans' updates into a branch in his GIT repository)
- David: This is cool stuff Hans, but the 2,700 line commit with the comment "make stuff work" and the varying 3,4,7 and 9 space indents mixed with tabs trouble me. Can you fix that?
- Hans: I'm terribly busy making some money over here David and what I've done is very important. Can someone out there polish up those tiresome flaws and work our David's complaints?
- SomeGuyOnTheList: Gosh, I really need BaseCamp integration. I'll try to help.
(various conversations, patches and history rewriting occur between SomeGuy and Hans)
- SomeGuyOnTheList: Hey David, I've worked with Hans this past week or so and its a lot cleaner now. You want to pull the latest version from Hans or my repo?
- David (pulling the latest version): The vastly improved state of this code puts a song in my heart! I am no longer a man whose will has been broken by the travails of building concensus in a community with divergent interests! I am free and I shall happily commit these changes!

(a vast cheer goes up from ERP-less small businesses everywhere)

This fairytale can easily become a reality because, unlike the Linux community in its time of darkness, the tools to make it happen are a solved problem. We merely have to borrow best practices from our friends who can both provide us examples and advice if we need it.

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Adrian Crum]

Ean Schuessler wrote:

> ----- "Jacopo Cappellato" wrote:
>> thanks for sharing your thoughts about our strategy about committers and commit rights.
>> If we are not happy about the results of our last resolutions we can review and rethink it, I am wide open to discuss this.
>> We actually may want to explore the following strategy:
>> 1) do not change commit rights but
>> 2) define some sort of hierarchy where "junior" committers are assigned to "senior" committers that are responsible for validating the work they do in specific areas
>
> This is exactly the way things are handled in the Linux kernel and exactly why Adam and I have been excitedly calling out "use GIT, use GIT!". The kernel team long ago ran into the problems of scaling control with the size of the contributing community. Originally they handled everything as a bunch of shell scripts that glued a workflow together out of tar balls and patchsets. Eventually that gave way to BitKeeper, which was up to the task but crippled by its proprietary nature. That lead to GIT.
>
> In my mind, we should clone the Linux source management model because what we are running into is already a solved problem for them. There should be a very limited (perhaps even 1 or 2) number of people who commit directly to the SVN repository and those 1 or 2 people should be primarily focused on architecture and style rather than developing new features. Under this model, a commit process might look like this:
>
> (Advance warning: there are mild comedic elements in this exchange. Adjust mental tone to "positive".)
>
> - Hans: I've just radically expanded the ProjectManager to automatically synchronize itself with todo-items on BaseCamp, JIRA, DebBugs, Bugzilla and LaunchPad.
> - David: Wow, that's interesting, let me take a look at that. (pulls a copy of Hans' updates into a branch in his GIT repository)
> - David: This is cool stuff Hans, but the 2,700 line commit with the comment "make stuff work" and the varying 3,4,7 and 9 space indents mixed with tabs trouble me. Can you fix that?
> - Hans: I'm terribly busy making some money over here David and what I've done is very important. Can someone out there polish up those tiresome flaws and work our David's complaints?
> - SomeGuyOnTheList: Gosh, I really need BaseCamp integration. I'll try to help.
> (various conversations, patches and history rewriting occur between SomeGuy and Hans)
> - SomeGuyOnTheList: Hey David, I've worked with Hans this past week or so and its a lot cleaner now. You want to pull the latest version from Hans or my repo?
> - David (pulling the latest version): The vastly improved state of this code puts a song in my heart! I am no longer a man whose will has been broken by the travails of building concensus in a community with divergent interests! I am free and I shall happily commit these changes!
>
> (a vast cheer goes up from ERP-less small businesses everywhere)
>
> This fairytale can easily become a reality because, unlike the Linux community in its time of darkness, the tools to make it happen are a solved problem. We merely have to borrow best practices from our friends who can both provide us examples and advice if we need it.

But I wanted unicorns.

[Tim Ruppert]

+1 - and thanks for laying it out Ean. I guess the only question remains is what stops us from moving in this direction if we can achieve exactly what Ean's talking about?  This sounds like something that would allow all of us the ability to manage the pieces we want to without polluting the code base with internal initiatives.

Alas, I do feel like this might be a huge departure for many - but this seems like it might fix many of the contentious issues that waste a ton of time around here.

Cheers,
Ruppert

On Mar 11, 2010, at 9:24 AM, Ean Schuessler wrote:

> ----- "Jacopo Cappellato" wrote:
>> thanks for sharing your thoughts about our strategy about committers and commit rights.
>> If we are not happy about the results of our last resolutions we can review and rethink it, I am wide open to discuss this.
>> We actually may want to explore the following strategy:
>> 1) do not change commit rights but
>> 2) define some sort of hierarchy where "junior" committers are assigned to "senior" committers that are responsible for validating the work they do in specific areas
>
> This is exactly the way things are handled in the Linux kernel and exactly why Adam and I have been excitedly calling out "use GIT, use GIT!". The kernel team long ago ran into the problems of scaling control with the size of the contributing community. Originally they handled everything as a bunch of shell scripts that glued a workflow together out of tar balls and patchsets. Eventually that gave way to BitKeeper, which was up to the task but crippled by its proprietary nature. That lead to GIT.
>
> In my mind, we should clone the Linux source management model because what we are running into is already a solved problem for them. There should be a very limited (perhaps even 1 or 2) number of people who commit directly to the SVN repository and those 1 or 2 people should be primarily focused on architecture and style rather than developing new features. Under this model, a commit process might look like this:
>
> (Advance warning: there are mild comedic elements in this exchange. Adjust mental tone to "positive".)
>
> - Hans: I've just radically expanded the ProjectManager to automatically synchronize itself with todo-items on BaseCamp, JIRA, DebBugs, Bugzilla and LaunchPad.
> - David: Wow, that's interesting, let me take a look at that. (pulls a copy of Hans' updates into a branch in his GIT repository)
> - David: This is cool stuff Hans, but the 2,700 line commit with the comment "make stuff work" and the varying 3,4,7 and 9 space indents mixed with tabs trouble me. Can you fix that?
> - Hans: I'm terribly busy making some money over here David and what I've done is very important. Can someone out there polish up those tiresome flaws and work our David's complaints?
> - SomeGuyOnTheList: Gosh, I really need BaseCamp integration. I'll try to help.
> (various conversations, patches and history rewriting occur between SomeGuy and Hans)
> - SomeGuyOnTheList: Hey David, I've worked with Hans this past week or so and its a lot cleaner now. You want to pull the latest version from Hans or my repo?
> - David (pulling the latest version): The vastly improved state of this code puts a song in my heart! I am no longer a man whose will has been broken by the travails of building concensus in a community with divergent interests! I am free and I shall happily commit these changes!
>
> (a vast cheer goes up from ERP-less small businesses everywhere)
>
> This fairytale can easily become a reality because, unlike the Linux community in its time of darkness, the tools to make it happen are a solved problem. We merely have to borrow best practices from our friends who can both provide us examples and advice if we need it.
>
> --
> Ean Schuessler, CTO Brainfood.com
> [hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Jacopo Cappellato-4]

Hi Ean,

this is interesting but comparing two very different products like OFBiz and the Linux kernel is an extreme practice; also the size of the OFBiz community is far smaller and we don't have a lot of help/contributions (out of the committers group). But of course things could change over time.

Jacopo

On Mar 11, 2010, at 5:24 PM, Ean Schuessler wrote:

> ----- "Jacopo Cappellato" wrote:
>> thanks for sharing your thoughts about our strategy about committers and commit rights.
>> If we are not happy about the results of our last resolutions we can review and rethink it, I am wide open to discuss this.
>> We actually may want to explore the following strategy:
>> 1) do not change commit rights but
>> 2) define some sort of hierarchy where "junior" committers are assigned to "senior" committers that are responsible for validating the work they do in specific areas
>
> This is exactly the way things are handled in the Linux kernel and exactly why Adam and I have been excitedly calling out "use GIT, use GIT!". The kernel team long ago ran into the problems of scaling control with the size of the contributing community. Originally they handled everything as a bunch of shell scripts that glued a workflow together out of tar balls and patchsets. Eventually that gave way to BitKeeper, which was up to the task but crippled by its proprietary nature. That lead to GIT.
>
> In my mind, we should clone the Linux source management model because what we are running into is already a solved problem for them. There should be a very limited (perhaps even 1 or 2) number of people who commit directly to the SVN repository and those 1 or 2 people should be primarily focused on architecture and style rather than developing new features. Under this model, a commit process might look like this:
>
> (Advance warning: there are mild comedic elements in this exchange. Adjust mental tone to "positive".)
>
> - Hans: I've just radically expanded the ProjectManager to automatically synchronize itself with todo-items on BaseCamp, JIRA, DebBugs, Bugzilla and LaunchPad.
> - David: Wow, that's interesting, let me take a look at that. (pulls a copy of Hans' updates into a branch in his GIT repository)
> - David: This is cool stuff Hans, but the 2,700 line commit with the comment "make stuff work" and the varying 3,4,7 and 9 space indents mixed with tabs trouble me. Can you fix that?
> - Hans: I'm terribly busy making some money over here David and what I've done is very important. Can someone out there polish up those tiresome flaws and work our David's complaints?
> - SomeGuyOnTheList: Gosh, I really need BaseCamp integration. I'll try to help.
> (various conversations, patches and history rewriting occur between SomeGuy and Hans)
> - SomeGuyOnTheList: Hey David, I've worked with Hans this past week or so and its a lot cleaner now. You want to pull the latest version from Hans or my repo?
> - David (pulling the latest version): The vastly improved state of this code puts a song in my heart! I am no longer a man whose will has been broken by the travails of building concensus in a community with divergent interests! I am free and I shall happily commit these changes!
>
> (a vast cheer goes up from ERP-less small businesses everywhere)
>
> This fairytale can easily become a reality because, unlike the Linux community in its time of darkness, the tools to make it happen are a solved problem. We merely have to borrow best practices from our friends who can both provide us examples and advice if we need it.
>
> --
> Ean Schuessler, CTO Brainfood.com
> [hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Adam Heath-2]

Adrian Crum wrote:

> Adam Heath wrote:
>> Moving the caching higher implies that the constructed delegator won't
>> be saved until it is completely done being constructed.  However,
>> during construction, the delegator creates several helper entities.
>> These include EntityCrypto, and the cache support classes.  These
>> classes also still have the same problem of not storing delegator
>> instances, instead just storing a name.  So, they try to load a
>> delegator with the correct name, and don't find it, because the
>> original delegator is not done being constructed.
>>
>> But, we still aren't done with this particular problem.
>>
>> When GenericPK and GenericValue get created, they try to set their
>> fields.  Setting any field on a GenericEntity requires that it knows
>> it's delegator.  However, creation doesn't actually set the delegator.
>>  Even the delegator name is null.  So any GenericEntity created during
>> delegator instantiation ends up trying to load a delegator named
>> "default", *not* with whatever delegator is actually being created.
>
> I ran into that circular logic problem in the ExecutionContext branch. I
> agree - there are a lot of problems with the delegator implementation
> and they should be fixed. Let me know if there is anything I can do to
> help.

Oh, heh, funny you should say that.

Your DelegatorFactory change gave me many problems.  It's not
backwards compatible.

Webslinger is a purely standalone framework.  It's made to run in
anything, with anything.  It just happens to have a way to function
alongside ofbiz.

The issue here, is that I have to produce updates to the webslinger
codebase, and make them work against multiple ofbiz versions.  I
support 595296 thru 902021.  Making it work against the latest
version, with the delegator interface/class changes, was rather
complex.  I had to copy the old GenericDelegator class, erasing all
documentation, all code, make every method throw an
UnsupportedOperationException.  I did this so I would have an
api-compatible version, that I could compile against.  I then had to
make my build system compile 2 versions of webslinger, one against the
latest ofbiz, and one against an old ofbiz with this special dummy
GenericDelegator class earlier in the classpath.

When making changes to ofbiz, it's not just the internal project code
that has to be made consistent.  Ofbiz doesn't exist by itself.  It
has to deal with external addons, that aren't even known.  As such,
much care needs to be taken any time you change the abi(not api).
This was not done with the DelegatorFactory change.  I even mentioned
this briefly during it's inception.  But I never spoke up in detail
about it at the time.

Also, any time a class changes(I'm saying this again, but it bears
repeating), you need to consider the use cases of it.  This paragraph
is talking about the moving of some classes from util to lang, with no
 attention paid to backwards compatiblity, nor deprecation.  If an end
developer has to maintain multiple versions of their product against
multiple versions of ofbiz, then changing abi like this causes *more*
work for end developers.

Any time you change something, and someone finds a problem with it,
don't take the defensive, and say "How dare you find faults with my
work; I'm not going to fix this, as it's just more work for me to do."
 In actuallity, you have caused more work for the person who found the
problem.  You have broken their own software; you have made them
dislike the project as a whole.

Absolutely be defensive in your programming.  Whenever you do
something, say to yourself: "How could this be used?  Is it perfect?
Will it break things for other people, thereby causing them more work?"

And, when someone *does* find something wrong, don't respond saying
that the finder should fix the issue.  *You* are the one who did the
original change, and are the absolutely bestest person to understand
what was being attempted.  You are the perfect person to fix the
actual problem.

As for real things to deal with:

This applies to anyone reading this.  Read that Java Concurrency in
Practice book *again(, cover to cover.  All constructors must *only*
set variables internal to their *direct* class.  Do *not* construct
other classes, passing 'this' to them, because they may register
themselves in global static containers.  This means that 'this' is
available for use by other parts of the system, before 'this' is
actually finished being constructed.

[Adam Heath-2]

Tim Ruppert wrote:
> +1 - and thanks for laying it out Ean. I guess the only question remains is what stops us from moving in this direction if we can achieve exactly what Ean's talking about?  This sounds like something that would allow all of us the ability to manage the pieces we want to without polluting the code base with internal initiatives.
>
> Alas, I do feel like this might be a huge departure for many - but this seems like it might fix many of the contentious issues that waste a ton of time around here.

It's unfortunate, but even tho Ean and I have be evangelizing ofbiz, I
can't recommend at the time it's use for managing ofbiz code.

Right now, ofbiz has a single source for any changes.  svn on apache.
 If suddenly we start going the distributed route, then were will
official changes come from?  Who will step up to be responsible for
pulling code from everyone else?  I don't think there is anyone in
this community who is willing to spend this huge amount of time, just
being a code aggregator.  It's an expensive position.

[Adrian Crum]

David E Jones wrote:
> After reading enough similar comments from a number of people in recent weeks I think I'm starting to come around to a different way of looking at things, and I think I know how to fix all of these community problems with people not getting along and the software quality falling well below industry standards.

I will ask the same question I asked before: Why do think you need to
"fix" the community?

I don't see where the community has changed considerably lately. Maybe
it's just your perception that has changed. I've been involved with
OFBiz for six years, and the kind of things you feel need fixing have
been going on all along. A quick review of the dev mailing list will
prove that.

I would be against any initiative to scale back commit privileges. That
would take us back to the days when only a handful of people had those
privileges and OFBiz stagnated as a result. We have seen explosive
growth in the project recently and, in my opinion, that growth can be
attributed to the number of committers we have.

The recent discussions that seem to have some people upset are not a bad
thing. Those discussions prove that people are involved and willing to
participate. That is a good thing from my perspective. It is not
something that needs to be "fixed."

As far as code quality is concerned, I don't believe it is fair to blame
poor quality on unnamed "inexperienced" programmers. The fault lies in
the design philosophy that has always been a part of this project: "Just
enough rope to shoot yourself in the foot." I could go back and retrieve
emails where I argued for code that is well structured, but I was shot
down because "we don't want to make things too difficult for the
developers." Well structured, well designed code might steepen the
learning curve for some, but the payoff is a more reliable code base.

If Hans wants to pack up his marbles and go home, then let him. The rest
of us will continue to participate on the community process. We don't
need to be "fixed." If Hans leaves, it's not because the community is
broken, it's because he isn't willing to cooperate.

-Adrian