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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Adam Heath-2
Adrian Crum wrote:

> 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.

Your email was great, except for these last 2 paragraphs.  Too combative.

Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Tim Ruppert
In reply to this post by Adam Heath-2
Yeah - after I responded to this, I remembered you discussing this previously and wondered if something had changed.  The position of aggregator is a huge on in this process - but something we should consider if it gives us the flexibility and wherewithal to make better decisions longer term.  Anyways, thanks for the info gents - it was informative and something I'd like to look further into for sure.

Cheers,
Ruppert

On Mar 11, 2010, at 9:57 AM, Adam Heath wrote:

> 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.

Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Adrian Crum
In reply to this post by Adam Heath-2
Adam Heath wrote:

> 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.

Please keep in mind that was your design. Also keep in mind that David
has been warning the community for some time that even more
backwards-incompatible changes are on the way.

> 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.

You're preaching to the choir here. I tried to keep things backwards
compatible, but you and David argued against it.

> 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.

The only classes that were moved were new ones that shouldn't cause any
compatibility issues. You don't see me complaining about all of the
converter classes you moved around.

> 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.

Are you speaking rhetorically? As far as I know I have been receptive to
comments about my code. I'm always willing to revert any of my changes
that cause problems.


Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

David E. Jones-2

On Mar 11, 2010, at 10:20 AM, Adrian Crum wrote:

> Adam Heath wrote:
>> 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.
>
> Please keep in mind that was your design. Also keep in mind that David has been warning the community for some time that even more backwards-incompatible changes are on the way.
>
>> 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.
>
> You're preaching to the choir here. I tried to keep things backwards compatible, but you and David argued against it.

Adrian, don't you dare. That is ridiculous, untrue, and unfair. You did it. Don't blame others. I was also against the changes you were making and spoke up about it, but you ignored those comments.

You bring up my name in order to justify your actions? I completely disapprove and I now ask you out of respect to not refer to me in this way, ever again. If it helps you may simply not refer to me at all.

Quite frankly, if I could undo everything you and certain others have done in the project without having to resolve innumerable dependencies and invest an enormous amount of time... well that would be tempting. That's not an option though, and I don't think it would be a good idea for the community either (community over code!), so I wouldn't pursue or even seriously propose such a thing. There are always other ways to move forward...

-David


>> 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.
>
> The only classes that were moved were new ones that shouldn't cause any compatibility issues. You don't see me complaining about all of the converter classes you moved around.
>
>> 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.
>
> Are you speaking rhetorically? As far as I know I have been receptive to comments about my code. I'm always willing to revert any of my changes that cause problems.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Adrian Crum
David E Jones wrote:
> Adrian, don't you dare. That is ridiculous, untrue, and unfair. You did it. Don't blame others. I was also against the changes you were making and spoke up about it, but you ignored those comments.

I tried to bring your execution context code into the trunk a piece at a
time. You objected to that - that's true. I tried to bring that code
over in a way that was backwards compatible, and Adam objected to that.
So, I reverted it. The code that is in the project now is a design Adam
proposed and I implemented.

I can see this is a sensitive subject. I apologize for offending you.

> You bring up my name in order to justify your actions? I completely disapprove and I now ask you out of respect to not refer to me in this way, ever again. If it helps you may simply not refer to me at all.

I wasn't trying to justify anything. I was speaking historically.

Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Jacques Le Roux
Administrator
In reply to this post by Adam Heath-2
From: "Adam Heath" <[hidden email]>

> 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.

I don't use this. You don't need it most of the time. But I'm rarely playing with deep OFBiz code, I must say.

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Jacques Le Roux
Administrator
In reply to this post by Adam Heath-2
From: "Adam Heath" <[hidden email]>

> 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.


I agree. Moreover, I'm (slowly) reading the article Bruno suggested and I don't think the way the releases are done in Linux makes
sense for us (odd and even release for unstable and stable for instance, etc.).
I still support the Ubuntu way + possibly milestones/RC, like Eclipse does ( 4.2RC1, ... 4.2RC6, 4.2). Please KISS...

Jacques


Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Jacques Le Roux
Administrator
In reply to this post by David E. Jones-2
From: "David E Jones" <[hidden email]>

> On Mar 11, 2010, at 10:20 AM, Adrian Crum wrote:
>
>> Adam Heath wrote:
>>> 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.
>>
>> Please keep in mind that was your design. Also keep in mind that David has been warning the community for some time that even
>> more backwards-incompatible changes are on the way.
>>
>>> 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.
>>
>> You're preaching to the choir here. I tried to keep things backwards compatible, but you and David argued against it.
>
> Adrian, don't you dare. That is ridiculous, untrue, and unfair. You did it. Don't blame others. I was also against the changes you
> were making and spoke up about it, but you ignored those comments.
>
> You bring up my name in order to justify your actions? I completely disapprove and I now ask you out of respect to not refer to me
> in this way, ever again. If it helps you may simply not refer to me at all.
>
> Quite frankly, if I could undo everything you and certain others have done in the project without having to resolve innumerable
> dependencies and invest an enormous amount of time... well that would be tempting. That's not an option though, and I don't think
> it would be a good idea for the community either (community over code!), so I wouldn't pursue or even seriously propose such a
> thing. There are always other ways to move forward...
>
> -David

Beautiful answer, Adam's comment ;o) ?

Jacques

>
>>> 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.
>>
>> The only classes that were moved were new ones that shouldn't cause any compatibility issues. You don't see me complaining about
>> all of the converter classes you moved around.
>>
>>> 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.
>>
>> Are you speaking rhetorically? As far as I know I have been receptive to comments about my code. I'm always willing to revert any
>> of my changes that cause problems.
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Adrian Crum
In reply to this post by David E. Jones-2
David E Jones wrote:
> Quite frankly, if I could undo everything you and certain others have done in the project without having to resolve innumerable dependencies and invest an enormous amount of time... well that would be tempting. That's not an option though, and I don't think it would be a good idea for the community either (community over code!), so I wouldn't pursue or even seriously propose such a thing. There are always other ways to move forward...

I'm sure all of the committers have felt the same way at one time or
another. Fortunately for the project, no single person is in charge.
Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

BJ Freeman
In reply to this post by Tim Ruppert
The reality is there no motivation for anyone to create a review
systems, otherwise it would be in place
even with all we have, no one has taken the lead to be the review
coordinator

to hans that is using the svn to his customers, I see this the cart
before the horse.
if you have developed and tested in your own svn then a patch submitted
once it is supplied to the client, and checked out.


=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Adam Heath sent the following on 3/11/2010 8:57 AM:

> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Ean Schuessler
In reply to this post by Jacques Le Roux
----- "Jacques Le Roux" wrote:
> I agree. Moreover, I'm (slowly) reading the article Bruno suggested and I don't think the way the releases are done in Linux makes
> sense for us (odd and even release for unstable and stable for instance, etc.).
> I still support the Ubuntu way + possibly milestones/RC, like Eclipse does ( 4.2RC1, ... 4.2RC6, 4.2). Please KISS...

Technically I believe what Si Chen has been practicing would be more of the Ubuntu Way(tm). **

** This joke is true because Ubuntu primarily rebrands Debian and upsells it without much credit (in the marketing that count) to the origin of the work and its ongoing development.

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