Ofbiz Contribution Proposal

["Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>]

Hi,

 

we use Ofbiz (mostly the entity engine) for over 2 years now.

 

Last year I had mail contact with David.

 

He recommended to contribute changes to the Ofbiz Community regularly whenever possible and useful. 

 

It is a long time since this happened, but we finally convinced our management to try

 

to contribute some changes and extensions to the Ofbiz community.

 

I read the FAQ and found out that especially complex changes might take a long time

 

and we may need some "community attendance".

 

David told me to place our proposal at the Ofbiz-WIKI

and to send a link to this mailing list.  

 

This is our "trial balloon" to find out whether our changes and improvements

 

are welcome and how we could integrate them during the next months. 

 

I.e. the following extensions may also be interesting for other members 

of the community:

 

 * Advanced custom SQL integration 

 * advanced sorting (locale, collation, natural sort) 

 * completely refactored TransactionUtil with documentation and hints 

 * on-demand "real"-sql-logging for ALL ofbiz statements 

... 

 

I placed our stuff at http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal

and hope one of the "Ofbiz gurus" will have a look at the attached stuff to make a statement.

 

Thank you in advance!

 

Best regards

 

Karl Eilebrecht

-- 
Karl Eilebrecht
Key-Work Consulting GmbH

Kriegsstr. 100 - 76133 Karlsruhe - Germany
Fon: +49-721-78203-277 - Fax: +49-721-78203-10
karl.eilebrecht@key-work.de


Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
Geschäftsführer: Andreas Stappert, Tobin Wotring

Re: Ofbiz Contribution Proposal

[BJ Freeman <bj...@free-man.net>]

+1

David E. Jones sent the following on 4/20/2007 7:52 PM:
> 
> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> 
>> We shouldn't turn away complex contributions anymore.
> 
> "We" do not now, nor have we ever, turned away a contribution because it
> was complex.
> 
>> I myself have loads of enhancements (mostly to widget module) that I
>> feel uneasy about releasing to the community, simply because of this
>> odd use of trunk: it's used like a slow-moving release branch that is
>> unable to handle introductions of radical enhancements.
>>
>> Yet, this somewhat slow-moving trunk isn't still enough and focused
>> enough on achieving release-quality stability. It's the worst of both
>> worlds: it's not rapid enough to allow for radical progress, and not
>> calm and focused-on-cleaning-up enough to produce a stable release for
>> non-OFBiz developers.
> 
> Could you do us all a big favor Jonathon? Your comments seem to be
> fairly consistent along these lines. I think what would be helpful to
> you, and to anyone reading and agreeing with your comments, is to step
> back and try to explain why things are the way they are. Feel free to
> share that with the group for a sanity check if you'd like.
> 
> -David
> 
> 

Re: Post Branch Enhancements (was Re: Ofbiz Contribution Proposal)

[Jacques Le Roux <ja...@les7arts.com>]

Sorry Chris,

I did not read your message before "answering" to Jonathon, so I kept
the wrong thread (Re: Ofbiz Contribution Proposal)

Jacques

De : "Chris Howe" <cj...@yahoo.com>
Objet : Re: Post Branch Enhancements (was Re: Ofbiz Contribution
Proposal)


> All,
> Again, can we please not hijack threads.  We have relatively few eyes
> that understand the underpinnings of the entity-engine enough to
> possibly improve upon it that it would be a shame for that discussion
> to get lost in the noise of project administration discussion.
>
> Jonathon,
> Hmph, I only have about ten patches in Jira that affect OFBiz code
> directly (thus would suffer from difficulty in sharing a progressed
> revision) and none of them seem to have comment from you.  It's one
> thing to leach code; we yield that risk by using the Apache license
> specifically and OSS in general, however it seems counter-intuitive to
> take the time to review code enough to put it into your private
project
> but not offer the constructive criticism necessary to get it improved
> upon or draw the attention of others to get it into the project.
>
> This seems like a lose-lose-lose approach.  You're forced to maintain
> obscure code on your own, the author is forced to maintain or abandon
> the obscure code and the community doesn't gain the benefit of the
code
> or the administrative benefit of knowing to ignore the contribution if
> it's not a good idea for the project.
>
>
>
> --- Jonathon -- Improov <jo...@improov.com> wrote:
>
> > Tim,
> >
> > I've already taken those "first steps" long ago. Like I said, I
don't
> > know which Jira "feature
> > requests" are not reviewed; I only know those I have merged into my
> > own SVN. I really don't have
> > time to send up itemized or clearly demarcated patches.
> >
> > Many patches I grabbed from folks (sorry I did it so fast, I don't
> > even know who), they work. Some
> > require streamlining mainly to match OFBiz coding standards and
such,
> > but still they do work. By
> > now, radical patches (like those from Chris Howes?) have gone
through
> > merging, and have even taken
> > a life (progressed) of their own. That's why I can't tell you "which
> > Jira issues", because my
> > "private Jira store", so to speak, has "moved on". If I can do this
> > aggressively merging without
> > problems (please use branches for sanity's sake), I am assuming the
> > community of 400 here can do
> > the same, if not better. (And I'm guessing a good majority of this
> > 400 might just be doing what I
> > am doing, and OFBiz is none the better for it.)
> >
> > For now, let's just all do what we're good at, and keep at it. Maybe
> > some day, I can submit a
> > gigantic patch and it will somehow translate into a bigger better
> > OFBiz. For now, I can't help but
> > leech off of OFBiz, every single update, but still can't feed the
> > whole sum back to OFBiz. Tough
> > on my conscience, but something I'll have to live with.
> >
> > By the way, I have no idea what some folks here are intending to
> > achieve with some off-tangent
> > remarks. If it's "status quo" they want (in relation to me and "my"
> > patches, ie), they've got it.
> >
> > If you can understand what I'm doing in my own computers (with OFBiz
> > and radical patches), that's
> > good and you may do the same good(?) thing in time. If not, I may
> > change my bad(?) tactics over
> > time. Either way, let's just get back to what we're good at.
> >
> > Jonathon
> >
> > Tim Ruppert wrote:
> > > Jonathon - as has always been the case - the role of reviewing
> > "complex"
> > > patches does not fall strictly on the committers - it falls on the
> > > entire community.  The committers then have the role of putting
the
> > code
> > > into the trunk.
> > >
> > > If you are so concerned that valid works are not being put back
> > into the
> > > trunk aggressively enough (which I think that everyone who spends
> > time
> > > over here would agree), could you try the proactive approach of
> > looking
> > > at more patches and letting the community know which ones you
think
> > are
> > > tested well enough and offer enough value to go back into the
> > trunk?
> > > That would be a GREAT first step and a very nice change of pace
> > from the
> > > aggressive tone you seem to think is appropriate.
> > >
> > > Cheers,
> > > Tim
> > > --
> > > Tim Ruppert
> > > HotWax Media
> > > http://www.hotwaxmedia.com
> > >
> > > o:801.649.6594
> > > f:801.649.6595
> > >
> > >
> > > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
> > >
> > >> David,
> > >>
> > >> > "We" do not now, nor have we ever, turned away a contribution
> > because it
> > >> > was complex.
> > >>
> > >> Very well, I'll just use the word "you" then. I take it that you
> > do
> > >> not turn away contributions because they were complex.
> > >>
> > >> The question from me would be whether you do or do not turn away,
> > >> knowingly or not, contributions that are valid but too complex
for
> >
> > >> review. It's not rhetorical, but you're free to do your own
> > >> sanity/verification checks on that supposed phenomenon and deem
it
> >
> > >> rhetorical or invalid.
> > >>
> > >> > Could you do us all a big favor Jonathon? Your comments seem to
> > be
> > >> > fairly consistent along these lines. I think what would be
> > helpful to
> > >> > you, and to anyone reading and agreeing with your comments, is
> > to step
> > >> > back and try to explain why things are the way they are. Feel
> > free to
> > >> > share that with the group for a sanity check if you'd like.
> > >>
> > >> I'm not so sure of the "why" of things, but am only more certain
> > of
> > >> the "what" of things. Things are the way they are, no matter how
> > we
> > >> interpret the "why".
> > >>
> > >> So, for now, I continue to merge in (to my own SVN) several
> > >> contributions that are deemed too difficult to review/merge by
the
> >
> > >> committers. I continue to keep such enhancements in step with
> > updates
> > >> from OFBiz trunk. And I continue in my failure(?) to feed such
> > >> "compatibilized/merged" enhancements back to OFBiz trunk even
> > though
> > >> they really are the same license.
> > >>
> > >> And the phenomenon of several of us (incompatible contributors?)
> > >> holding on to our own enhancements will continue. Some of us may
> > not
> > >> know how to keep in step with OFBiz trunk updates; others may.
> > Those
> > >> of us who can keep in step will continue to benefit from OFBiz
> > >> progress, but be unable to feed the benefit back to OFBiz. There
> > will
> > >> still be enhancements out there that are kept away/apart from
> > OFBiz.
> > >> That's the way of things? Or maybe not?
> > >>
> > >> I stand corrected. I think I am "helping" OFBiz in the wrong way.
> > I'll
> > >> stop that. :) Thanks for reminding me.
> > >>
> > >> I was waiting to dump the loads of my enhancements into your
> > trunk,
> > >> but I think I should take a sanity check for now. Anyway, there
> > needs
> > >> to be at least one stabilizing branch (save point, so to speak)
> > before
> > >> we can go full steam with the trunk. And there's still no such
> > branch yet.
> > >>
> > >> Jonathon
> > >>
> > >> David E. Jones wrote:
> > >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> > >>>> We shouldn't turn away complex contributions anymore.
> > >>> "We" do not now, nor have we ever, turned away a contribution
> > because
> > >>> it was complex.
> > >>>> I myself have loads of enhancements (mostly to widget module)
> > that I
> > >>>> feel uneasy about releasing to the community, simply because of
> > this
> > >>>> odd use of trunk: it's used like a slow-moving release branch
> > that
> > >>>> is unable to handle introductions of radical enhancements.
> > >>>>
> > >>>> Yet, this somewhat slow-moving trunk isn't still enough and
> > focused
> > >>>> enough on achieving release-quality stability. It's the worst
of
> >
> > >>>> both worlds: it's not rapid enough to allow for radical
> > progress,
> > >>>> and not calm and focused-on-cleaning-up enough to produce a
> > stable
> > >>>> release for non-OFBiz developers.
> > >>> Could you do us all a big favor Jonathon? Your comments seem to
> > be
> > >>> fairly consistent along these lines. I think what would be
> > helpful to
> > >>> you, and to anyone reading and agreeing with your comments, is
to
> >
> > >>> step back and try to explain why things are the way they are.
> > Feel
> > >>> free to share that with the group for a sanity check if you'd
> > like.
> > >>> -David
> > >>
> > >
> >
> >

Re: Post Branch Enhancements (was Re: Ofbiz Contribution Proposal)

[Jonathon -- Improov <jo...@improov.com>]

Chris,

The patches/enhancements I bring in are not totally "assessed/reviewed", if that's what you mean 
by "review code". I only begin to take apart pinpointed portions of those enhancements when I need 
to. I'll try to explain again how I work: I really don't know OFBiz, but I pinpoint exact portions 
of what needs to be changed for what effect.

If you know how little time it takes for me to assimilate (like the bad old Borgs, if you watch 
Star Trek?) your enhancements into my little playground, you'll likely call me crazy or careless 
or both. I don't know how to explain this anymore, except to say that SVN does allow us to be that 
reckless, and it does provide facilities for us to minimize risks.

I can probably only give you a counter example.

Have you seen developers stare at a somewhat small portion of code, albeit core codes in 
framework, and think and rethink over weeks about immediate directions? Ever seen a group of 5-10 
developers discuss that small portion over and over, and go on to project 
repercussions/ramifications for each direction that is suggested? It's as if this group of 
developers expect ZERO human error to occur. That's not how we should force us humans to work. We 
make mistakes, live with that. We just need to devise mechanisms to minimize the 
risks/repurcussions of those mistakes. If you play computer games, you'll know a mechanism called 
"save games" or something.

We can't have "save points" in real life, can't go back in time. But did you know that version 
control systems, with their branch and "timeline" concepts, allow us to border on reckless while 
giving us ability to drastically minimize costs of mistakes?

Imagine if you could start multiple branches in your real life. You could try out being a movie 
star, a casanova, a do-gooder. Each branch perfectly insulated from the others, no rippling effect 
for whatever mistakes you made. Wouldn't you be bolder and more reckless in your moves?

Incidentally, I have a personal motto: Fail fast to learn fast. If you don't try things quickly, 
you won't find out quickly that you were wrong. Problem-solving by "process of RAPID elimination" 
is very efficient: it's easier to say "what doesn't work" than to say "what does work (in all 
universal cases)". You'd have to test a solution in all universal cases for the 2nd type of proof.

I don't know how else to explain these concepts. At the risk of being misconstrued as 
"un-helpful", I'm gonna just stop here for such topics, and leave OFBiz to it's way of handling 
the "real life" that is the OFBiz SVN. Maybe I could be all wrong.

Jonathon

Chris Howe wrote:
> All, 
> Again, can we please not hijack threads.  We have relatively few eyes
> that understand the underpinnings of the entity-engine enough to
> possibly improve upon it that it would be a shame for that discussion
> to get lost in the noise of project administration discussion.
> 
> Jonathon,
> Hmph, I only have about ten patches in Jira that affect OFBiz code
> directly (thus would suffer from difficulty in sharing a progressed
> revision) and none of them seem to have comment from you.  It's one
> thing to leach code; we yield that risk by using the Apache license
> specifically and OSS in general, however it seems counter-intuitive to
> take the time to review code enough to put it into your private project
> but not offer the constructive criticism necessary to get it improved
> upon or draw the attention of others to get it into the project.  
> 
> This seems like a lose-lose-lose approach.  You're forced to maintain
> obscure code on your own, the author is forced to maintain or abandon
> the obscure code and the community doesn't gain the benefit of the code
> or the administrative benefit of knowing to ignore the contribution if
> it's not a good idea for the project.
> 
> 
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
>> Tim,
>>
>> I've already taken those "first steps" long ago. Like I said, I don't
>> know which Jira "feature 
>> requests" are not reviewed; I only know those I have merged into my
>> own SVN. I really don't have 
>> time to send up itemized or clearly demarcated patches.
>>
>> Many patches I grabbed from folks (sorry I did it so fast, I don't
>> even know who), they work. Some 
>> require streamlining mainly to match OFBiz coding standards and such,
>> but still they do work. By 
>> now, radical patches (like those from Chris Howes?) have gone through
>> merging, and have even taken 
>> a life (progressed) of their own. That's why I can't tell you "which
>> Jira issues", because my 
>> "private Jira store", so to speak, has "moved on". If I can do this
>> aggressively merging without 
>> problems (please use branches for sanity's sake), I am assuming the
>> community of 400 here can do 
>> the same, if not better. (And I'm guessing a good majority of this
>> 400 might just be doing what I 
>> am doing, and OFBiz is none the better for it.)
>>
>> For now, let's just all do what we're good at, and keep at it. Maybe
>> some day, I can submit a 
>> gigantic patch and it will somehow translate into a bigger better
>> OFBiz. For now, I can't help but 
>> leech off of OFBiz, every single update, but still can't feed the
>> whole sum back to OFBiz. Tough 
>> on my conscience, but something I'll have to live with.
>>
>> By the way, I have no idea what some folks here are intending to
>> achieve with some off-tangent 
>> remarks. If it's "status quo" they want (in relation to me and "my"
>> patches, ie), they've got it.
>>
>> If you can understand what I'm doing in my own computers (with OFBiz
>> and radical patches), that's 
>> good and you may do the same good(?) thing in time. If not, I may
>> change my bad(?) tactics over 
>> time. Either way, let's just get back to what we're good at.
>>
>> Jonathon
>>
>> Tim Ruppert wrote:
>>> Jonathon - as has always been the case - the role of reviewing
>> "complex" 
>>> patches does not fall strictly on the committers - it falls on the 
>>> entire community.  The committers then have the role of putting the
>> code 
>>> into the trunk. 
>>>
>>> If you are so concerned that valid works are not being put back
>> into the 
>>> trunk aggressively enough (which I think that everyone who spends
>> time 
>>> over here would agree), could you try the proactive approach of
>> looking 
>>> at more patches and letting the community know which ones you think
>> are 
>>> tested well enough and offer enough value to go back into the
>> trunk?  
>>> That would be a GREAT first step and a very nice change of pace
>> from the 
>>> aggressive tone you seem to think is appropriate.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>>
>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
>>>
>>>> David,
>>>>
>>>>> "We" do not now, nor have we ever, turned away a contribution
>> because it
>>>>> was complex.
>>>> Very well, I'll just use the word "you" then. I take it that you
>> do 
>>>> not turn away contributions because they were complex.
>>>>
>>>> The question from me would be whether you do or do not turn away, 
>>>> knowingly or not, contributions that are valid but too complex for
>>>> review. It's not rhetorical, but you're free to do your own 
>>>> sanity/verification checks on that supposed phenomenon and deem it
>>>> rhetorical or invalid.
>>>>
>>>>> Could you do us all a big favor Jonathon? Your comments seem to
>> be
>>>>> fairly consistent along these lines. I think what would be
>> helpful to
>>>>> you, and to anyone reading and agreeing with your comments, is
>> to step
>>>>> back and try to explain why things are the way they are. Feel
>> free to
>>>>> share that with the group for a sanity check if you'd like.
>>>> I'm not so sure of the "why" of things, but am only more certain
>> of 
>>>> the "what" of things. Things are the way they are, no matter how
>> we 
>>>> interpret the "why".
>>>>
>>>> So, for now, I continue to merge in (to my own SVN) several 
>>>> contributions that are deemed too difficult to review/merge by the
>>>> committers. I continue to keep such enhancements in step with
>> updates 
>>>> from OFBiz trunk. And I continue in my failure(?) to feed such 
>>>> "compatibilized/merged" enhancements back to OFBiz trunk even
>> though 
>>>> they really are the same license.
>>>>
>>>> And the phenomenon of several of us (incompatible contributors?) 
>>>> holding on to our own enhancements will continue. Some of us may
>> not 
>>>> know how to keep in step with OFBiz trunk updates; others may.
>> Those 
>>>> of us who can keep in step will continue to benefit from OFBiz 
>>>> progress, but be unable to feed the benefit back to OFBiz. There
>> will 
>>>> still be enhancements out there that are kept away/apart from
>> OFBiz. 
>>>> That's the way of things? Or maybe not?
>>>>
>>>> I stand corrected. I think I am "helping" OFBiz in the wrong way.
>> I'll 
>>>> stop that. :) Thanks for reminding me.
>>>>
>>>> I was waiting to dump the loads of my enhancements into your
>> trunk, 
>>>> but I think I should take a sanity check for now. Anyway, there
>> needs 
>>>> to be at least one stabilizing branch (save point, so to speak)
>> before 
>>>> we can go full steam with the trunk. And there's still no such
>> branch yet.
>>>> Jonathon
>>>>
>>>> David E. Jones wrote:
>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>>>>> We shouldn't turn away complex contributions anymore.
>>>>> "We" do not now, nor have we ever, turned away a contribution
>> because 
>>>>> it was complex.
>>>>>> I myself have loads of enhancements (mostly to widget module)
>> that I 
>>>>>> feel uneasy about releasing to the community, simply because of
>> this 
>>>>>> odd use of trunk: it's used like a slow-moving release branch
>> that 
>>>>>> is unable to handle introductions of radical enhancements.
>>>>>>
>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and
>> focused 
>>>>>> enough on achieving release-quality stability. It's the worst of
>>>>>> both worlds: it's not rapid enough to allow for radical
>> progress, 
>>>>>> and not calm and focused-on-cleaning-up enough to produce a
>> stable 
>>>>>> release for non-OFBiz developers.
>>>>> Could you do us all a big favor Jonathon? Your comments seem to
>> be 
>>>>> fairly consistent along these lines. I think what would be
>> helpful to 
>>>>> you, and to anyone reading and agreeing with your comments, is to
>>>>> step back and try to explain why things are the way they are.
>> Feel 
>>>>> free to share that with the group for a sanity check if you'd
>> like.
>>>>> -David
>>
> 
> 

Re: Post Branch Enhancements (was Re: Ofbiz Contribution Proposal)

[Chris Howe <cj...@yahoo.com>]

All, 
Again, can we please not hijack threads.  We have relatively few eyes
that understand the underpinnings of the entity-engine enough to
possibly improve upon it that it would be a shame for that discussion
to get lost in the noise of project administration discussion.

Jonathon,
Hmph, I only have about ten patches in Jira that affect OFBiz code
directly (thus would suffer from difficulty in sharing a progressed
revision) and none of them seem to have comment from you.  It's one
thing to leach code; we yield that risk by using the Apache license
specifically and OSS in general, however it seems counter-intuitive to
take the time to review code enough to put it into your private project
but not offer the constructive criticism necessary to get it improved
upon or draw the attention of others to get it into the project.  

This seems like a lose-lose-lose approach.  You're forced to maintain
obscure code on your own, the author is forced to maintain or abandon
the obscure code and the community doesn't gain the benefit of the code
or the administrative benefit of knowing to ignore the contribution if
it's not a good idea for the project.



--- Jonathon -- Improov <jo...@improov.com> wrote:

> Tim,
> 
> I've already taken those "first steps" long ago. Like I said, I don't
> know which Jira "feature 
> requests" are not reviewed; I only know those I have merged into my
> own SVN. I really don't have 
> time to send up itemized or clearly demarcated patches.
> 
> Many patches I grabbed from folks (sorry I did it so fast, I don't
> even know who), they work. Some 
> require streamlining mainly to match OFBiz coding standards and such,
> but still they do work. By 
> now, radical patches (like those from Chris Howes?) have gone through
> merging, and have even taken 
> a life (progressed) of their own. That's why I can't tell you "which
> Jira issues", because my 
> "private Jira store", so to speak, has "moved on". If I can do this
> aggressively merging without 
> problems (please use branches for sanity's sake), I am assuming the
> community of 400 here can do 
> the same, if not better. (And I'm guessing a good majority of this
> 400 might just be doing what I 
> am doing, and OFBiz is none the better for it.)
> 
> For now, let's just all do what we're good at, and keep at it. Maybe
> some day, I can submit a 
> gigantic patch and it will somehow translate into a bigger better
> OFBiz. For now, I can't help but 
> leech off of OFBiz, every single update, but still can't feed the
> whole sum back to OFBiz. Tough 
> on my conscience, but something I'll have to live with.
> 
> By the way, I have no idea what some folks here are intending to
> achieve with some off-tangent 
> remarks. If it's "status quo" they want (in relation to me and "my"
> patches, ie), they've got it.
> 
> If you can understand what I'm doing in my own computers (with OFBiz
> and radical patches), that's 
> good and you may do the same good(?) thing in time. If not, I may
> change my bad(?) tactics over 
> time. Either way, let's just get back to what we're good at.
> 
> Jonathon
> 
> Tim Ruppert wrote:
> > Jonathon - as has always been the case - the role of reviewing
> "complex" 
> > patches does not fall strictly on the committers - it falls on the 
> > entire community.  The committers then have the role of putting the
> code 
> > into the trunk. 
> > 
> > If you are so concerned that valid works are not being put back
> into the 
> > trunk aggressively enough (which I think that everyone who spends
> time 
> > over here would agree), could you try the proactive approach of
> looking 
> > at more patches and letting the community know which ones you think
> are 
> > tested well enough and offer enough value to go back into the
> trunk?  
> > That would be a GREAT first step and a very nice change of pace
> from the 
> > aggressive tone you seem to think is appropriate.
> > 
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> > 
> > o:801.649.6594
> > f:801.649.6595
> > 
> > 
> > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
> > 
> >> David,
> >>
> >> > "We" do not now, nor have we ever, turned away a contribution
> because it
> >> > was complex.
> >>
> >> Very well, I'll just use the word "you" then. I take it that you
> do 
> >> not turn away contributions because they were complex.
> >>
> >> The question from me would be whether you do or do not turn away, 
> >> knowingly or not, contributions that are valid but too complex for
> 
> >> review. It's not rhetorical, but you're free to do your own 
> >> sanity/verification checks on that supposed phenomenon and deem it
> 
> >> rhetorical or invalid.
> >>
> >> > Could you do us all a big favor Jonathon? Your comments seem to
> be
> >> > fairly consistent along these lines. I think what would be
> helpful to
> >> > you, and to anyone reading and agreeing with your comments, is
> to step
> >> > back and try to explain why things are the way they are. Feel
> free to
> >> > share that with the group for a sanity check if you'd like.
> >>
> >> I'm not so sure of the "why" of things, but am only more certain
> of 
> >> the "what" of things. Things are the way they are, no matter how
> we 
> >> interpret the "why".
> >>
> >> So, for now, I continue to merge in (to my own SVN) several 
> >> contributions that are deemed too difficult to review/merge by the
> 
> >> committers. I continue to keep such enhancements in step with
> updates 
> >> from OFBiz trunk. And I continue in my failure(?) to feed such 
> >> "compatibilized/merged" enhancements back to OFBiz trunk even
> though 
> >> they really are the same license.
> >>
> >> And the phenomenon of several of us (incompatible contributors?) 
> >> holding on to our own enhancements will continue. Some of us may
> not 
> >> know how to keep in step with OFBiz trunk updates; others may.
> Those 
> >> of us who can keep in step will continue to benefit from OFBiz 
> >> progress, but be unable to feed the benefit back to OFBiz. There
> will 
> >> still be enhancements out there that are kept away/apart from
> OFBiz. 
> >> That's the way of things? Or maybe not?
> >>
> >> I stand corrected. I think I am "helping" OFBiz in the wrong way.
> I'll 
> >> stop that. :) Thanks for reminding me.
> >>
> >> I was waiting to dump the loads of my enhancements into your
> trunk, 
> >> but I think I should take a sanity check for now. Anyway, there
> needs 
> >> to be at least one stabilizing branch (save point, so to speak)
> before 
> >> we can go full steam with the trunk. And there's still no such
> branch yet.
> >>
> >> Jonathon
> >>
> >> David E. Jones wrote:
> >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> >>>> We shouldn't turn away complex contributions anymore.
> >>> "We" do not now, nor have we ever, turned away a contribution
> because 
> >>> it was complex.
> >>>> I myself have loads of enhancements (mostly to widget module)
> that I 
> >>>> feel uneasy about releasing to the community, simply because of
> this 
> >>>> odd use of trunk: it's used like a slow-moving release branch
> that 
> >>>> is unable to handle introductions of radical enhancements.
> >>>>
> >>>> Yet, this somewhat slow-moving trunk isn't still enough and
> focused 
> >>>> enough on achieving release-quality stability. It's the worst of
> 
> >>>> both worlds: it's not rapid enough to allow for radical
> progress, 
> >>>> and not calm and focused-on-cleaning-up enough to produce a
> stable 
> >>>> release for non-OFBiz developers.
> >>> Could you do us all a big favor Jonathon? Your comments seem to
> be 
> >>> fairly consistent along these lines. I think what would be
> helpful to 
> >>> you, and to anyone reading and agreeing with your comments, is to
> 
> >>> step back and try to explain why things are the way they are.
> Feel 
> >>> free to share that with the group for a sanity check if you'd
> like.
> >>> -David
> >>
> > 
> 
> 

Re: Post Branch Enhancements

[Jonathon -- Improov <jo...@improov.com>]

Jacques,

Yes, that seems to be the best way. Only I don't have time to even do the Jira issues (I'd have to 
split up my enhancements neatly).

But don't worry. My stuff is always kept in step (playing well) with the latest OFBiz trunk 
revision. It wouldn't be difficult to reconcile my stuff into OFBiz trunk when I finally do have 
time to look into that effort.

Thanks.

Jonathon

Jacques Le Roux wrote:
> Jonathon,
> 
> I thought about all that and at this point I believe, regarding licence
> issues, the only way is for you
> 
> 1. to create Jira issues for your own proper additions/modifications
> (being careful to don't mix "joint work", and checking ASL granted of
> course)
> 2. to comment in existing Jira issues the results of your tests (and
> vote if positive) to help commiters and accelerate commits
> 
> Hope this help and you agree
> 
> Jacques

Re: Post Branch Enhancements

[Jonathon -- Improov <jo...@improov.com>]

Jacques,

Yes, that seems to be the best way. Only I don't have time to even do the Jira issues (I'd have to 
split up my enhancements neatly).

But don't worry. My stuff is always kept in step (playing well) with the latest OFBiz trunk 
revision. It wouldn't be difficult to reconcile my stuff into OFBiz trunk when I finally do have 
time to look into that effort.

Thanks.

Jonathon

Jacques Le Roux wrote:
> Jonathon,
> 
> I thought about all that and at this point I believe, regarding licence
> issues, the only way is for you
> 
> 1. to create Jira issues for your own proper additions/modifications
> (being careful to don't mix "joint work", and checking ASL granted of
> course)
> 2. to comment in existing Jira issues the results of your tests (and
> vote if positive) to help commiters and accelerate commits
> 
> Hope this help and you agree
> 
> Jacques
> 
>> Jacques,
>>
>> Glad I seem to be making sense to you. Please pardon my inability to
> explain some concepts; I'm
>> more a worker than a teacher/discusser.
>>
>>  > To be able to test your changes it'd be really better to at least
> have
>>  > an idea of the features that are added (or withdrawed f any). If
> they
>>  > are many changes and we don't know which they are, just funding our
>>  > reviewing work from a diff might be a nightmare.
>>
>> Yes, every commit does have some comments about what is added or
> changed. However, there are also
>> some comments that say: "Brought in Chris Howe's Rico experiment.".
> Again, the trick is I brought
>> in a huge wide-spanning stuff on a short-lived exploratory branch.
> Sort of like me saying, "Let me
>> try out being a casanova for a short time, just a quick try". I'm not
> a casanova, not
>> french/italian (sorry for stereotype, blame the movies), and I'd
> probably get in a lot of trouble
>> for trying. But SVN is not like real life.
>>
>> My ability/inability to "compatibilize" a huge patch with my work will
> determine whether or not
>> the exploratory branch dies or gets merged into my trunk. If I do have
> a casanova in me, I can try
>> some casanova lifestyle in the "main branch (trunk)" of my life; if
> not, that exploratory branch
>> gets pruned off for good, never to be merged into my trunk.
>>
>>  > Yes I understand your POV. It stays that merging your change might
> be a
>>  > challenge.
>>
>> No more a challenge than merging OFBiz trunk into our own work, due to
> the instability of the
>> trunk. If you recall, there are some folks who tried to "marry latest
> of OFiz with own
>> enhancements", and they failed.
>>
>> If I can use exploratory branches to bring in OFBiz trunk updates
> _wholesale_ (my commit logs go
>> like "brought in OFBiz trunk r123:456), the question still remains:
> Should it be that tough for
>> OFBiz SVN to bring in radical enhancements the way I bring in OFBiz
> trunk updates?
>> OFBiz trunk updates, especially when they span a week, are just as
> "radical/un-atomic" as the
>> enhancements Karl or the rest of us try to submit.
>>
>>  > Also remember this discussion we had with Chris (and others) about
>>  > "joint work" and licence. This is perhaps the worse issue in your
> case !
>>  > You may Googlize or use Nabble if you need explanations...
>>
>> That's why I was following Chris Howes' dissertations on the "joint
> work" issue.
>> I've since read the ASL 2.0.
>>
>> Merging my changes shouldn't be that difficult, since I only pull in
> stuff from JIRA and other
>> donations clearly labelled as ASL. Unless... I misunderstood that all
> patches/comments in JIRA
>> were explicitly contributed under ASL.
>>
>> As with all merges, the further the deviation (given time), the more
> difficult to reconcile.
>> Karl's contribution was 2 years in the making; that's 1.99 years too
> late to bring in. Yet, that
>> is still earlier than 2.01 years. The longer we wait (eg "please hold,
> we're busy, we'll look into
>> your enhancements soon"), the more difficult to reconcile.
>>
>> Similarly, for the release branch, there really is no point at all in
> waiting to fork one. OFBiz
>> is already very full-featured as it is now; it's a different case when
> OFBiz has not even ONE
>> function working.
>>
>> Hope all that makes sense to you.
>>
>> Jonathon
>>
>> Jacques Le Roux wrote:
>>> Jonathon,
>>>
>>> You should read other messages, then you w'd have seen Chris's about
> the
>>> new thread. Ok not a big deal. ;o)
>>>
>>> Happy that you did not feel my last message "rude" and that your
> answer
>>> is understandable by me (I must aknowledge that sometimes you lost
> me).
>>> Perhaps kepping the habit of using numbered points will help our
>>> communication (we have to keep it as concise as possible), trying :
>>>
>>> Seems that only the 3d point needs some comments, they are inline...
>>>
>>>
>>> ----- Message d'origine ----- 
>>> De : "Jonathon -- Improov" <jo...@improov.com>
>>> À : <de...@ofbiz.apache.org>
>>> Envoyé : dimanche 22 avril 2007 12:27
>>> Objet : Re: Ofbiz Contribution Proposal
>>>
>>>
>>>> Jacques,
>>>>
>>>> You lost me. I don't see where you are (or were ever) rude.
>>>>
>>>>  > a. You have your own branch(es) of OFBiz
>>>>
>>>> Yes, I have multiple branches sometimes, which will stabilize and
>>> collapse into a few (possibly 2
>>>> or 3) branches, and then eventually come down to trunk.
>>>>
>>>> Usually, when I see a huge patch(es) I might like, I'll see many
>>> branches popping up.
>>>>  > b. Not using our standard strategy (moving with the community,
>>>>  > not alone) you "losed" the control about the changes you made
>>>>  > respectively to the OFBiz trunk
>>>>
>>>> Hmm. That didn't happen.
>>>>
>>>> The trick is to keep a record of exactly where you branched off, to
>>> know how and which
>>>> files/folders to do a diff. Of course, you'll need to know which
>>> direction to do the diff-patch.
>>>>  > c. This is not a problem for you (your branch is a fork but good
>>>>  > for you)
>>>>
>>>> If my branch isn't kept in step with OFBiz trunk, that's not ok for
>>> me. The OFBiz trunk is
>>>> constantly getting updates and bugfixes. Like I said, the "loss of
>>> control" didn't happen. I am
>>>> still in step with OFBiz trunk. Only issue I have is that the OFBiz
>>> trunk can't keep in step with
>>>> my own updates, which is fine by me if I really don't mind kicking
>>> back and relaxing after
>>>> finishing my own work.
>>>>
>>>>  > d. You don't have time to extract your changes atomically but
>>>>  > with a huge patch (unusable by commiters)
>>>>
>>>> You're right on this count. Due to the way I perform wholesale
>>> aggressive merges (to bring in big
>>>> enhancements), my commits are not small. They are quite mostly
> large
>>> and wide in scope. I perform
>>>> such wholesale merges, then somehow systematically pick off all
>>> incompatibilities.
>>>> Hence, I can only feed large patches to the community, not atomic
> ones
>>> like "Added feature A" or
>>>> "Fixed bug B".
>>>>
>>>>  > 3. So your only solution to have your changes in the trunk is
> for
>>> us to
>>>>  > open a branch for you
>>>>
>>>> No, the solution is for myself to give you a patch that will bring
> 2
>>> things together: the latest
>>>> of OFBiz and the latest of my work. I can tell you that I've tested
>>> this patch, but it's really up
>>>> to the community to trust me.
>>>>
>>>> On your part, the solution would be to just dump my patch into your
>>> trunk. Or if you want to have
>>>> a cautious look-see first, you could open a new branch just to test
>>> out my patch. This
>>>> "exploratory/probationary" branch will be very short-lived,
> possibly
>>> 2-3 updates in the timeline.
>>>> After the few updates, you can decide:
>>>>
>>>> a. My patch is playing well with the latest of OFBiz, and you merge
> it
>>> into
>>>>     trunk.
>>>>
>>>> OR
>>>>
>>>> b. My patch still has too many incompatibilities with OFBiz, and
> you
>>> discard
>>>>     it.
>>> To be able to test your changes it'd be really better to at least
> have
>>> an idea of the features that are added (or withdrawed f any). If
> they
>>> are many changes and we don't know which they are, just funding our
>>> reviewing work from a diff might be a nightmare.
>>>
>>>
>>>> As you can see, the bulk of the work is on my part, in "bringing
> the
>>> latest of OFBiz and my work
>>>> together". The fact that I already have the latest of OFBiz playing
>>> with my enhancements is
>>>> already more than half the work done.
>>>>
>>>> Most folks I come across don't know how to do that part. I was
>>> suggesting that someone among us,
>>>> someone comfortable with version control adventures, perform that
>>> merge for those who can't.
>>>
>>> Following http://tinyurl.com/2o5bld this should not be too hard I
> guess.
>>> Even for people (like me for instance) that have never played with
>>> branches in their own work (ok I have an advantage : I read the
> book)
>>>> I'm gonna assume you understand the concepts I tried to describe
>>> above. It's dinner time now.
>>>> Ultimately, the concepts involve "maximizing concurrency". It won't
> be
>>> good if I find myself
>>>> limiting my rate/size of progress just so I don't "lose control" or
>>> lose sight of OFBiz trunk. I
>>>> just moved ahead at full speed, all the while being confident that
>>> OFBiz trunk will always be
>>>> mergeable into my SVN. The question is whether the OFBiz SVN is
>>> similarly confident about merging
>>>> our mad-cap-paced work into OFBiz trunk.
>>> Yes I understand your POV. It stays that merging your change might
> be a
>>> challenge. And I'm not sure who will want to take it or rather have
>>> enough "free" time to do it.  Explaining clearly what these changes
>>> might bring to OFBiz (at the businnes and technical levels) would
> surely
>>> be a *1st step* in this direction.
>>>
>>> Please, don't misunderstand me. Here, I'm trying to find a way to be
>>> able to merge your changes because I'm sure they are worth it.
>>>
>>> Also remember this discussion we had with Chris (and others) about
>>> "joint work" and licence. This is perhaps the worse issue in your
> case !
>>> You may Googlize or use Nabble if you need explanations...
>>>
>>> Jacques
>>>
>>>> Jonathon
>>>>
>>>> Jacques Le Roux wrote:
>>>>> Jonathon,
>>>>>
>>>>> I don't want to be agressive or let you thing that I like to make
>>>>> "off-tangent" remarks. Here is what I think (I can't tell that
>>> facts):
>>>>> 1. I'm sure you might be able to be a great help for the
> community.
>>>>> 2. I better understand now why you'd like to have an "open"
> branch,
>>>>> correct me if I'm wrong
>>>>>     a. You have your own branch(es) of OFBiz
>>>>>     b. Not using our standard strategy (moving with the community,
>>> not
>>>>> alone) you "losed" the control about the changes you made
>>> respectively
>>>>> to the OFBiz trunk
>>>>>     c. This is not a problem for you (your branch is a fork but
> good
>>> for
>>>>> you)
>>>>>     d. You don't have time to extract your changes atomically but
>>> with a
>>>>> huge patch (unusable by commiters)
>>>>> 3. So your only solution to have your changes in the trunk is for
> us
>>> to
>>>>> open a branch for you
>>>>>
>>>>> Okay I'm a bit rude but you forced me and that's really what I
>>> think.
>>>>> Of course I'm open to discussion, you may also pass by my
> comments.
>>>>> Sorry and good luck
>>>>>
>>>>> Jacques
>>>>>
>>>>> ----- Message d'origine ----- 
>>>>> De : "Jonathon -- Improov" <jo...@improov.com>
>>>>> À : <de...@ofbiz.apache.org>
>>>>> Envoyé : dimanche 22 avril 2007 04:21
>>>>> Objet : Re: Ofbiz Contribution Proposal
>>>>>
>>>>>
>>>>>> Tim,
>>>>>>
>>>>>> I've already taken those "first steps" long ago. Like I said, I
>>> don't
>>>>> know which Jira "feature
>>>>>> requests" are not reviewed; I only know those I have merged into
> my
>>>>> own SVN. I really don't have
>>>>>> time to send up itemized or clearly demarcated patches.
>>>>>>
>>>>>> Many patches I grabbed from folks (sorry I did it so fast, I
> don't
>>>>> even know who), they work. Some
>>>>>> require streamlining mainly to match OFBiz coding standards and
>>> such,
>>>>> but still they do work. By
>>>>>> now, radical patches (like those from Chris Howes?) have gone
>>> through
>>>>> merging, and have even taken
>>>>>> a life (progressed) of their own. That's why I can't tell you
>>> "which
>>>>> Jira issues", because my
>>>>>> "private Jira store", so to speak, has "moved on". If I can do
> this
>>>>> aggressively merging without
>>>>>> problems (please use branches for sanity's sake), I am assuming
> the
>>>>> community of 400 here can do
>>>>>> the same, if not better. (And I'm guessing a good majority of
> this
>>> 400
>>>>> might just be doing what I
>>>>>> am doing, and OFBiz is none the better for it.)
>>>>>>
>>>>>> For now, let's just all do what we're good at, and keep at it.
>>> Maybe
>>>>> some day, I can submit a
>>>>>> gigantic patch and it will somehow translate into a bigger better
>>>>> OFBiz. For now, I can't help but
>>>>>> leech off of OFBiz, every single update, but still can't feed the
>>>>> whole sum back to OFBiz. Tough
>>>>>> on my conscience, but something I'll have to live with.
>>>>>>
>>>>>> By the way, I have no idea what some folks here are intending to
>>>>> achieve with some off-tangent
>>>>>> remarks. If it's "status quo" they want (in relation to me and
> "my"
>>>>> patches, ie), they've got it.
>>>>>> If you can understand what I'm doing in my own computers (with
>>> OFBiz
>>>>> and radical patches), that's
>>>>>> good and you may do the same good(?) thing in time. If not, I may
>>>>> change my bad(?) tactics over
>>>>>> time. Either way, let's just get back to what we're good at.
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> Tim Ruppert wrote:
>>>>>>> Jonathon - as has always been the case - the role of reviewing
>>>>> "complex"
>>>>>>> patches does not fall strictly on the committers - it falls on
> the
>>>>>>> entire community.  The committers then have the role of putting
>>> the
>>>>> code
>>>>>>> into the trunk.
>>>>>>>
>>>>>>> If you are so concerned that valid works are not being put back
>>> into
>>>>> the
>>>>>>> trunk aggressively enough (which I think that everyone who
> spends
>>>>> time
>>>>>>> over here would agree), could you try the proactive approach of
>>>>> looking
>>>>>>> at more patches and letting the community know which ones you
>>> think
>>>>> are
>>>>>>> tested well enough and offer enough value to go back into the
>>> trunk?
>>>>>>> That would be a GREAT first step and a very nice change of pace
>>> from
>>>>> the
>>>>>>> aggressive tone you seem to think is appropriate.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Tim
>>>>>>> --
>>>>>>> Tim Ruppert
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> o:801.649.6594
>>>>>>> f:801.649.6595
>>>>>>>
>>>>>>>
>>>>>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>>> "We" do not now, nor have we ever, turned away a contribution
>>>>> because it
>>>>>>>>> was complex.
>>>>>>>> Very well, I'll just use the word "you" then. I take it that
> you
>>> do
>>>>>>>> not turn away contributions because they were complex.
>>>>>>>>
>>>>>>>> The question from me would be whether you do or do not turn
> away,
>>>>>>>> knowingly or not, contributions that are valid but too complex
>>> for
>>>>>>>> review. It's not rhetorical, but you're free to do your own
>>>>>>>> sanity/verification checks on that supposed phenomenon and deem
>>> it
>>>>>>>> rhetorical or invalid.
>>>>>>>>
>>>>>>>>> Could you do us all a big favor Jonathon? Your comments seem
> to
>>>>> be
>>>>>>>>> fairly consistent along these lines. I think what would be
>>>>> helpful to
>>>>>>>>> you, and to anyone reading and agreeing with your comments, is
>>> to
>>>>> step
>>>>>>>>> back and try to explain why things are the way they are. Feel
>>>>> free to
>>>>>>>>> share that with the group for a sanity check if you'd like.
>>>>>>>> I'm not so sure of the "why" of things, but am only more
> certain
>>> of
>>>>>>>> the "what" of things. Things are the way they are, no matter
> how
>>> we
>>>>>>>> interpret the "why".
>>>>>>>>
>>>>>>>> So, for now, I continue to merge in (to my own SVN) several
>>>>>>>> contributions that are deemed too difficult to review/merge by
>>> the
>>>>>>>> committers. I continue to keep such enhancements in step with
>>>>> updates
>>>>>>>> from OFBiz trunk. And I continue in my failure(?) to feed such
>>>>>>>> "compatibilized/merged" enhancements back to OFBiz trunk even
>>>>> though
>>>>>>>> they really are the same license.
>>>>>>>>
>>>>>>>> And the phenomenon of several of us (incompatible
> contributors?)
>>>>>>>> holding on to our own enhancements will continue. Some of us
> may
>>>>> not
>>>>>>>> know how to keep in step with OFBiz trunk updates; others may.
>>>>> Those
>>>>>>>> of us who can keep in step will continue to benefit from OFBiz
>>>>>>>> progress, but be unable to feed the benefit back to OFBiz.
> There
>>>>> will
>>>>>>>> still be enhancements out there that are kept away/apart from
>>>>> OFBiz.
>>>>>>>> That's the way of things? Or maybe not?
>>>>>>>>
>>>>>>>> I stand corrected. I think I am "helping" OFBiz in the wrong
> way.
>>>>> I'll
>>>>>>>> stop that. :) Thanks for reminding me.
>>>>>>>>
>>>>>>>> I was waiting to dump the loads of my enhancements into your
>>> trunk,
>>>>>>>> but I think I should take a sanity check for now. Anyway, there
>>>>> needs
>>>>>>>> to be at least one stabilizing branch (save point, so to speak)
>>>>> before
>>>>>>>> we can go full steam with the trunk. And there's still no such
>>>>> branch yet.
>>>>>>>> Jonathon
>>>>>>>>
>>>>>>>> David E. Jones wrote:
>>>>>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>>>>>>>>> We shouldn't turn away complex contributions anymore.
>>>>>>>>> "We" do not now, nor have we ever, turned away a contribution
>>>>> because
>>>>>>>>> it was complex.
>>>>>>>>>> I myself have loads of enhancements (mostly to widget module)
>>>>> that I
>>>>>>>>>> feel uneasy about releasing to the community, simply because
> of
>>>>> this
>>>>>>>>>> odd use of trunk: it's used like a slow-moving release branch
>>>>> that
>>>>>>>>>> is unable to handle introductions of radical enhancements.
>>>>>>>>>>
>>>>>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and
>>>>> focused
>>>>>>>>>> enough on achieving release-quality stability. It's the worst
>>> of
>>>>>>>>>> both worlds: it's not rapid enough to allow for radical
>>> progress,
>>>>>>>>>> and not calm and focused-on-cleaning-up enough to produce a
>>>>> stable
>>>>>>>>>> release for non-OFBiz developers.
>>>>>>>>> Could you do us all a big favor Jonathon? Your comments seem
> to
>>> be
>>>>>>>>> fairly consistent along these lines. I think what would be
>>> helpful
>>>>> to
>>>>>>>>> you, and to anyone reading and agreeing with your comments, is
>>> to
>>>>>>>>> step back and try to explain why things are the way they are.
>>> Feel
>>>>>>>>> free to share that with the group for a sanity check if you'd
>>>>> like.
>>>>>>>>> -David
>>>
> 
> 

Re: Post Branch Enhancements

[Jacques Le Roux <ja...@les7arts.com>]

Jonathon,

I thought about all that and at this point I believe, regarding licence
issues, the only way is for you

1. to create Jira issues for your own proper additions/modifications
(being careful to don't mix "joint work", and checking ASL granted of
course)
2. to comment in existing Jira issues the results of your tests (and
vote if positive) to help commiters and accelerate commits

Hope this help and you agree

Jacques

> Jacques,
>
> Glad I seem to be making sense to you. Please pardon my inability to
explain some concepts; I'm
> more a worker than a teacher/discusser.
>
>  > To be able to test your changes it'd be really better to at least
have
>  > an idea of the features that are added (or withdrawed f any). If
they
>  > are many changes and we don't know which they are, just funding our
>  > reviewing work from a diff might be a nightmare.
>
> Yes, every commit does have some comments about what is added or
changed. However, there are also
> some comments that say: "Brought in Chris Howe's Rico experiment.".
Again, the trick is I brought
> in a huge wide-spanning stuff on a short-lived exploratory branch.
Sort of like me saying, "Let me
> try out being a casanova for a short time, just a quick try". I'm not
a casanova, not
> french/italian (sorry for stereotype, blame the movies), and I'd
probably get in a lot of trouble
> for trying. But SVN is not like real life.
>
> My ability/inability to "compatibilize" a huge patch with my work will
determine whether or not
> the exploratory branch dies or gets merged into my trunk. If I do have
a casanova in me, I can try
> some casanova lifestyle in the "main branch (trunk)" of my life; if
not, that exploratory branch
> gets pruned off for good, never to be merged into my trunk.
>
>  > Yes I understand your POV. It stays that merging your change might
be a
>  > challenge.
>
> No more a challenge than merging OFBiz trunk into our own work, due to
the instability of the
> trunk. If you recall, there are some folks who tried to "marry latest
of OFiz with own
> enhancements", and they failed.
>
> If I can use exploratory branches to bring in OFBiz trunk updates
_wholesale_ (my commit logs go
> like "brought in OFBiz trunk r123:456), the question still remains:
Should it be that tough for
> OFBiz SVN to bring in radical enhancements the way I bring in OFBiz
trunk updates?
>
> OFBiz trunk updates, especially when they span a week, are just as
"radical/un-atomic" as the
> enhancements Karl or the rest of us try to submit.
>
>  > Also remember this discussion we had with Chris (and others) about
>  > "joint work" and licence. This is perhaps the worse issue in your
case !
>  > You may Googlize or use Nabble if you need explanations...
>
> That's why I was following Chris Howes' dissertations on the "joint
work" issue.
>
> I've since read the ASL 2.0.
>
> Merging my changes shouldn't be that difficult, since I only pull in
stuff from JIRA and other
> donations clearly labelled as ASL. Unless... I misunderstood that all
patches/comments in JIRA
> were explicitly contributed under ASL.
>
> As with all merges, the further the deviation (given time), the more
difficult to reconcile.
> Karl's contribution was 2 years in the making; that's 1.99 years too
late to bring in. Yet, that
> is still earlier than 2.01 years. The longer we wait (eg "please hold,
we're busy, we'll look into
> your enhancements soon"), the more difficult to reconcile.
>
> Similarly, for the release branch, there really is no point at all in
waiting to fork one. OFBiz
> is already very full-featured as it is now; it's a different case when
OFBiz has not even ONE
> function working.
>
> Hope all that makes sense to you.
>
> Jonathon
>
> Jacques Le Roux wrote:
> > Jonathon,
> >
> > You should read other messages, then you w'd have seen Chris's about
the
> > new thread. Ok not a big deal. ;o)
> >
> > Happy that you did not feel my last message "rude" and that your
answer
> > is understandable by me (I must aknowledge that sometimes you lost
me).
> >
> > Perhaps kepping the habit of using numbered points will help our
> > communication (we have to keep it as concise as possible), trying :
> >
> > Seems that only the 3d point needs some comments, they are inline...
> >
> >
> > ----- Message d'origine ----- 
> > De : "Jonathon -- Improov" <jo...@improov.com>
> > À : <de...@ofbiz.apache.org>
> > Envoyé : dimanche 22 avril 2007 12:27
> > Objet : Re: Ofbiz Contribution Proposal
> >
> >
> >> Jacques,
> >>
> >> You lost me. I don't see where you are (or were ever) rude.
> >>
> >>  > a. You have your own branch(es) of OFBiz
> >>
> >> Yes, I have multiple branches sometimes, which will stabilize and
> > collapse into a few (possibly 2
> >> or 3) branches, and then eventually come down to trunk.
> >>
> >> Usually, when I see a huge patch(es) I might like, I'll see many
> > branches popping up.
> >>  > b. Not using our standard strategy (moving with the community,
> >>  > not alone) you "losed" the control about the changes you made
> >>  > respectively to the OFBiz trunk
> >>
> >> Hmm. That didn't happen.
> >>
> >> The trick is to keep a record of exactly where you branched off, to
> > know how and which
> >> files/folders to do a diff. Of course, you'll need to know which
> > direction to do the diff-patch.
> >>  > c. This is not a problem for you (your branch is a fork but good
> >>  > for you)
> >>
> >> If my branch isn't kept in step with OFBiz trunk, that's not ok for
> > me. The OFBiz trunk is
> >> constantly getting updates and bugfixes. Like I said, the "loss of
> > control" didn't happen. I am
> >> still in step with OFBiz trunk. Only issue I have is that the OFBiz
> > trunk can't keep in step with
> >> my own updates, which is fine by me if I really don't mind kicking
> > back and relaxing after
> >> finishing my own work.
> >>
> >>  > d. You don't have time to extract your changes atomically but
> >>  > with a huge patch (unusable by commiters)
> >>
> >> You're right on this count. Due to the way I perform wholesale
> > aggressive merges (to bring in big
> >> enhancements), my commits are not small. They are quite mostly
large
> > and wide in scope. I perform
> >> such wholesale merges, then somehow systematically pick off all
> > incompatibilities.
> >> Hence, I can only feed large patches to the community, not atomic
ones
> > like "Added feature A" or
> >> "Fixed bug B".
> >>
> >>  > 3. So your only solution to have your changes in the trunk is
for
> > us to
> >>  > open a branch for you
> >>
> >> No, the solution is for myself to give you a patch that will bring
2
> > things together: the latest
> >> of OFBiz and the latest of my work. I can tell you that I've tested
> > this patch, but it's really up
> >> to the community to trust me.
> >>
> >> On your part, the solution would be to just dump my patch into your
> > trunk. Or if you want to have
> >> a cautious look-see first, you could open a new branch just to test
> > out my patch. This
> >> "exploratory/probationary" branch will be very short-lived,
possibly
> > 2-3 updates in the timeline.
> >> After the few updates, you can decide:
> >>
> >> a. My patch is playing well with the latest of OFBiz, and you merge
it
> > into
> >>     trunk.
> >>
> >> OR
> >>
> >> b. My patch still has too many incompatibilities with OFBiz, and
you
> > discard
> >>     it.
> >
> > To be able to test your changes it'd be really better to at least
have
> > an idea of the features that are added (or withdrawed f any). If
they
> > are many changes and we don't know which they are, just funding our
> > reviewing work from a diff might be a nightmare.
> >
> >
> >> As you can see, the bulk of the work is on my part, in "bringing
the
> > latest of OFBiz and my work
> >> together". The fact that I already have the latest of OFBiz playing
> > with my enhancements is
> >> already more than half the work done.
> >>
> >> Most folks I come across don't know how to do that part. I was
> > suggesting that someone among us,
> >> someone comfortable with version control adventures, perform that
> > merge for those who can't.
> >
> > Following http://tinyurl.com/2o5bld this should not be too hard I
guess.
> > Even for people (like me for instance) that have never played with
> > branches in their own work (ok I have an advantage : I read the
book)
> >
> >> I'm gonna assume you understand the concepts I tried to describe
> > above. It's dinner time now.
> >> Ultimately, the concepts involve "maximizing concurrency". It won't
be
> > good if I find myself
> >> limiting my rate/size of progress just so I don't "lose control" or
> > lose sight of OFBiz trunk. I
> >> just moved ahead at full speed, all the while being confident that
> > OFBiz trunk will always be
> >> mergeable into my SVN. The question is whether the OFBiz SVN is
> > similarly confident about merging
> >> our mad-cap-paced work into OFBiz trunk.
> >
> > Yes I understand your POV. It stays that merging your change might
be a
> > challenge. And I'm not sure who will want to take it or rather have
> > enough "free" time to do it.  Explaining clearly what these changes
> > might bring to OFBiz (at the businnes and technical levels) would
surely
> > be a *1st step* in this direction.
> >
> > Please, don't misunderstand me. Here, I'm trying to find a way to be
> > able to merge your changes because I'm sure they are worth it.
> >
> > Also remember this discussion we had with Chris (and others) about
> > "joint work" and licence. This is perhaps the worse issue in your
case !
> > You may Googlize or use Nabble if you need explanations...
> >
> > Jacques
> >
> >> Jonathon
> >>
> >> Jacques Le Roux wrote:
> >>> Jonathon,
> >>>
> >>> I don't want to be agressive or let you thing that I like to make
> >>> "off-tangent" remarks. Here is what I think (I can't tell that
> > facts):
> >>> 1. I'm sure you might be able to be a great help for the
community.
> >>> 2. I better understand now why you'd like to have an "open"
branch,
> >>> correct me if I'm wrong
> >>>     a. You have your own branch(es) of OFBiz
> >>>     b. Not using our standard strategy (moving with the community,
> > not
> >>> alone) you "losed" the control about the changes you made
> > respectively
> >>> to the OFBiz trunk
> >>>     c. This is not a problem for you (your branch is a fork but
good
> > for
> >>> you)
> >>>     d. You don't have time to extract your changes atomically but
> > with a
> >>> huge patch (unusable by commiters)
> >>> 3. So your only solution to have your changes in the trunk is for
us
> > to
> >>> open a branch for you
> >>>
> >>> Okay I'm a bit rude but you forced me and that's really what I
> > think.
> >>> Of course I'm open to discussion, you may also pass by my
comments.
> >>>
> >>> Sorry and good luck
> >>>
> >>> Jacques
> >>>
> >>> ----- Message d'origine ----- 
> >>> De : "Jonathon -- Improov" <jo...@improov.com>
> >>> À : <de...@ofbiz.apache.org>
> >>> Envoyé : dimanche 22 avril 2007 04:21
> >>> Objet : Re: Ofbiz Contribution Proposal
> >>>
> >>>
> >>>> Tim,
> >>>>
> >>>> I've already taken those "first steps" long ago. Like I said, I
> > don't
> >>> know which Jira "feature
> >>>> requests" are not reviewed; I only know those I have merged into
my
> >>> own SVN. I really don't have
> >>>> time to send up itemized or clearly demarcated patches.
> >>>>
> >>>> Many patches I grabbed from folks (sorry I did it so fast, I
don't
> >>> even know who), they work. Some
> >>>> require streamlining mainly to match OFBiz coding standards and
> > such,
> >>> but still they do work. By
> >>>> now, radical patches (like those from Chris Howes?) have gone
> > through
> >>> merging, and have even taken
> >>>> a life (progressed) of their own. That's why I can't tell you
> > "which
> >>> Jira issues", because my
> >>>> "private Jira store", so to speak, has "moved on". If I can do
this
> >>> aggressively merging without
> >>>> problems (please use branches for sanity's sake), I am assuming
the
> >>> community of 400 here can do
> >>>> the same, if not better. (And I'm guessing a good majority of
this
> > 400
> >>> might just be doing what I
> >>>> am doing, and OFBiz is none the better for it.)
> >>>>
> >>>> For now, let's just all do what we're good at, and keep at it.
> > Maybe
> >>> some day, I can submit a
> >>>> gigantic patch and it will somehow translate into a bigger better
> >>> OFBiz. For now, I can't help but
> >>>> leech off of OFBiz, every single update, but still can't feed the
> >>> whole sum back to OFBiz. Tough
> >>>> on my conscience, but something I'll have to live with.
> >>>>
> >>>> By the way, I have no idea what some folks here are intending to
> >>> achieve with some off-tangent
> >>>> remarks. If it's "status quo" they want (in relation to me and
"my"
> >>> patches, ie), they've got it.
> >>>> If you can understand what I'm doing in my own computers (with
> > OFBiz
> >>> and radical patches), that's
> >>>> good and you may do the same good(?) thing in time. If not, I may
> >>> change my bad(?) tactics over
> >>>> time. Either way, let's just get back to what we're good at.
> >>>>
> >>>> Jonathon
> >>>>
> >>>> Tim Ruppert wrote:
> >>>>> Jonathon - as has always been the case - the role of reviewing
> >>> "complex"
> >>>>> patches does not fall strictly on the committers - it falls on
the
> >>>>> entire community.  The committers then have the role of putting
> > the
> >>> code
> >>>>> into the trunk.
> >>>>>
> >>>>> If you are so concerned that valid works are not being put back
> > into
> >>> the
> >>>>> trunk aggressively enough (which I think that everyone who
spends
> >>> time
> >>>>> over here would agree), could you try the proactive approach of
> >>> looking
> >>>>> at more patches and letting the community know which ones you
> > think
> >>> are
> >>>>> tested well enough and offer enough value to go back into the
> > trunk?
> >>>>> That would be a GREAT first step and a very nice change of pace
> > from
> >>> the
> >>>>> aggressive tone you seem to think is appropriate.
> >>>>>
> >>>>> Cheers,
> >>>>> Tim
> >>>>> --
> >>>>> Tim Ruppert
> >>>>> HotWax Media
> >>>>> http://www.hotwaxmedia.com
> >>>>>
> >>>>> o:801.649.6594
> >>>>> f:801.649.6595
> >>>>>
> >>>>>
> >>>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
> >>>>>
> >>>>>> David,
> >>>>>>
> >>>>>>> "We" do not now, nor have we ever, turned away a contribution
> >>> because it
> >>>>>>> was complex.
> >>>>>> Very well, I'll just use the word "you" then. I take it that
you
> > do
> >>>>>> not turn away contributions because they were complex.
> >>>>>>
> >>>>>> The question from me would be whether you do or do not turn
away,
> >>>>>> knowingly or not, contributions that are valid but too complex
> > for
> >>>>>> review. It's not rhetorical, but you're free to do your own
> >>>>>> sanity/verification checks on that supposed phenomenon and deem
> > it
> >>>>>> rhetorical or invalid.
> >>>>>>
> >>>>>>> Could you do us all a big favor Jonathon? Your comments seem
to
> >>> be
> >>>>>>> fairly consistent along these lines. I think what would be
> >>> helpful to
> >>>>>>> you, and to anyone reading and agreeing with your comments, is
> > to
> >>> step
> >>>>>>> back and try to explain why things are the way they are. Feel
> >>> free to
> >>>>>>> share that with the group for a sanity check if you'd like.
> >>>>>> I'm not so sure of the "why" of things, but am only more
certain
> > of
> >>>>>> the "what" of things. Things are the way they are, no matter
how
> > we
> >>>>>> interpret the "why".
> >>>>>>
> >>>>>> So, for now, I continue to merge in (to my own SVN) several
> >>>>>> contributions that are deemed too difficult to review/merge by
> > the
> >>>>>> committers. I continue to keep such enhancements in step with
> >>> updates
> >>>>>> from OFBiz trunk. And I continue in my failure(?) to feed such
> >>>>>> "compatibilized/merged" enhancements back to OFBiz trunk even
> >>> though
> >>>>>> they really are the same license.
> >>>>>>
> >>>>>> And the phenomenon of several of us (incompatible
contributors?)
> >>>>>> holding on to our own enhancements will continue. Some of us
may
> >>> not
> >>>>>> know how to keep in step with OFBiz trunk updates; others may.
> >>> Those
> >>>>>> of us who can keep in step will continue to benefit from OFBiz
> >>>>>> progress, but be unable to feed the benefit back to OFBiz.
There
> >>> will
> >>>>>> still be enhancements out there that are kept away/apart from
> >>> OFBiz.
> >>>>>> That's the way of things? Or maybe not?
> >>>>>>
> >>>>>> I stand corrected. I think I am "helping" OFBiz in the wrong
way.
> >>> I'll
> >>>>>> stop that. :) Thanks for reminding me.
> >>>>>>
> >>>>>> I was waiting to dump the loads of my enhancements into your
> > trunk,
> >>>>>> but I think I should take a sanity check for now. Anyway, there
> >>> needs
> >>>>>> to be at least one stabilizing branch (save point, so to speak)
> >>> before
> >>>>>> we can go full steam with the trunk. And there's still no such
> >>> branch yet.
> >>>>>> Jonathon
> >>>>>>
> >>>>>> David E. Jones wrote:
> >>>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> >>>>>>>> We shouldn't turn away complex contributions anymore.
> >>>>>>> "We" do not now, nor have we ever, turned away a contribution
> >>> because
> >>>>>>> it was complex.
> >>>>>>>> I myself have loads of enhancements (mostly to widget module)
> >>> that I
> >>>>>>>> feel uneasy about releasing to the community, simply because
of
> >>> this
> >>>>>>>> odd use of trunk: it's used like a slow-moving release branch
> >>> that
> >>>>>>>> is unable to handle introductions of radical enhancements.
> >>>>>>>>
> >>>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and
> >>> focused
> >>>>>>>> enough on achieving release-quality stability. It's the worst
> > of
> >>>>>>>> both worlds: it's not rapid enough to allow for radical
> > progress,
> >>>>>>>> and not calm and focused-on-cleaning-up enough to produce a
> >>> stable
> >>>>>>>> release for non-OFBiz developers.
> >>>>>>> Could you do us all a big favor Jonathon? Your comments seem
to
> > be
> >>>>>>> fairly consistent along these lines. I think what would be
> > helpful
> >>> to
> >>>>>>> you, and to anyone reading and agreeing with your comments, is
> > to
> >>>>>>> step back and try to explain why things are the way they are.
> > Feel
> >>>>>>> free to share that with the group for a sanity check if you'd
> >>> like.
> >>>>>>> -David
> >>>
> >
> >

Re: Post Branch Enhancements

[Jonathon -- Improov <jo...@improov.com>]

Jacques,

Glad I seem to be making sense to you. Please pardon my inability to explain some concepts; I'm 
more a worker than a teacher/discusser.

 > To be able to test your changes it'd be really better to at least have
 > an idea of the features that are added (or withdrawed f any). If they
 > are many changes and we don't know which they are, just funding our
 > reviewing work from a diff might be a nightmare.

Yes, every commit does have some comments about what is added or changed. However, there are also 
some comments that say: "Brought in Chris Howe's Rico experiment.". Again, the trick is I brought 
in a huge wide-spanning stuff on a short-lived exploratory branch. Sort of like me saying, "Let me 
try out being a casanova for a short time, just a quick try". I'm not a casanova, not 
french/italian (sorry for stereotype, blame the movies), and I'd probably get in a lot of trouble 
for trying. But SVN is not like real life.

My ability/inability to "compatibilize" a huge patch with my work will determine whether or not 
the exploratory branch dies or gets merged into my trunk. If I do have a casanova in me, I can try 
some casanova lifestyle in the "main branch (trunk)" of my life; if not, that exploratory branch 
gets pruned off for good, never to be merged into my trunk.

 > Yes I understand your POV. It stays that merging your change might be a
 > challenge.

No more a challenge than merging OFBiz trunk into our own work, due to the instability of the 
trunk. If you recall, there are some folks who tried to "marry latest of OFiz with own 
enhancements", and they failed.

If I can use exploratory branches to bring in OFBiz trunk updates _wholesale_ (my commit logs go 
like "brought in OFBiz trunk r123:456), the question still remains: Should it be that tough for 
OFBiz SVN to bring in radical enhancements the way I bring in OFBiz trunk updates?

OFBiz trunk updates, especially when they span a week, are just as "radical/un-atomic" as the 
enhancements Karl or the rest of us try to submit.

 > Also remember this discussion we had with Chris (and others) about
 > "joint work" and licence. This is perhaps the worse issue in your case !
 > You may Googlize or use Nabble if you need explanations...

That's why I was following Chris Howes' dissertations on the "joint work" issue.

I've since read the ASL 2.0.

Merging my changes shouldn't be that difficult, since I only pull in stuff from JIRA and other 
donations clearly labelled as ASL. Unless... I misunderstood that all patches/comments in JIRA 
were explicitly contributed under ASL.

As with all merges, the further the deviation (given time), the more difficult to reconcile. 
Karl's contribution was 2 years in the making; that's 1.99 years too late to bring in. Yet, that 
is still earlier than 2.01 years. The longer we wait (eg "please hold, we're busy, we'll look into 
your enhancements soon"), the more difficult to reconcile.

Similarly, for the release branch, there really is no point at all in waiting to fork one. OFBiz 
is already very full-featured as it is now; it's a different case when OFBiz has not even ONE 
function working.

Hope all that makes sense to you.

Jonathon

Jacques Le Roux wrote:
> Jonathon,
> 
> You should read other messages, then you w'd have seen Chris's about the
> new thread. Ok not a big deal. ;o)
> 
> Happy that you did not feel my last message "rude" and that your answer
> is understandable by me (I must aknowledge that sometimes you lost me).
> 
> Perhaps kepping the habit of using numbered points will help our
> communication (we have to keep it as concise as possible), trying :
> 
> Seems that only the 3d point needs some comments, they are inline...
> 
> 
> ----- Message d'origine ----- 
> De : "Jonathon -- Improov" <jo...@improov.com>
> À : <de...@ofbiz.apache.org>
> Envoyé : dimanche 22 avril 2007 12:27
> Objet : Re: Ofbiz Contribution Proposal
> 
> 
>> Jacques,
>>
>> You lost me. I don't see where you are (or were ever) rude.
>>
>>  > a. You have your own branch(es) of OFBiz
>>
>> Yes, I have multiple branches sometimes, which will stabilize and
> collapse into a few (possibly 2
>> or 3) branches, and then eventually come down to trunk.
>>
>> Usually, when I see a huge patch(es) I might like, I'll see many
> branches popping up.
>>  > b. Not using our standard strategy (moving with the community,
>>  > not alone) you "losed" the control about the changes you made
>>  > respectively to the OFBiz trunk
>>
>> Hmm. That didn't happen.
>>
>> The trick is to keep a record of exactly where you branched off, to
> know how and which
>> files/folders to do a diff. Of course, you'll need to know which
> direction to do the diff-patch.
>>  > c. This is not a problem for you (your branch is a fork but good
>>  > for you)
>>
>> If my branch isn't kept in step with OFBiz trunk, that's not ok for
> me. The OFBiz trunk is
>> constantly getting updates and bugfixes. Like I said, the "loss of
> control" didn't happen. I am
>> still in step with OFBiz trunk. Only issue I have is that the OFBiz
> trunk can't keep in step with
>> my own updates, which is fine by me if I really don't mind kicking
> back and relaxing after
>> finishing my own work.
>>
>>  > d. You don't have time to extract your changes atomically but
>>  > with a huge patch (unusable by commiters)
>>
>> You're right on this count. Due to the way I perform wholesale
> aggressive merges (to bring in big
>> enhancements), my commits are not small. They are quite mostly large
> and wide in scope. I perform
>> such wholesale merges, then somehow systematically pick off all
> incompatibilities.
>> Hence, I can only feed large patches to the community, not atomic ones
> like "Added feature A" or
>> "Fixed bug B".
>>
>>  > 3. So your only solution to have your changes in the trunk is for
> us to
>>  > open a branch for you
>>
>> No, the solution is for myself to give you a patch that will bring 2
> things together: the latest
>> of OFBiz and the latest of my work. I can tell you that I've tested
> this patch, but it's really up
>> to the community to trust me.
>>
>> On your part, the solution would be to just dump my patch into your
> trunk. Or if you want to have
>> a cautious look-see first, you could open a new branch just to test
> out my patch. This
>> "exploratory/probationary" branch will be very short-lived, possibly
> 2-3 updates in the timeline.
>> After the few updates, you can decide:
>>
>> a. My patch is playing well with the latest of OFBiz, and you merge it
> into
>>     trunk.
>>
>> OR
>>
>> b. My patch still has too many incompatibilities with OFBiz, and you
> discard
>>     it.
> 
> To be able to test your changes it'd be really better to at least have
> an idea of the features that are added (or withdrawed f any). If they
> are many changes and we don't know which they are, just funding our
> reviewing work from a diff might be a nightmare.
> 
> 
>> As you can see, the bulk of the work is on my part, in "bringing the
> latest of OFBiz and my work
>> together". The fact that I already have the latest of OFBiz playing
> with my enhancements is
>> already more than half the work done.
>>
>> Most folks I come across don't know how to do that part. I was
> suggesting that someone among us,
>> someone comfortable with version control adventures, perform that
> merge for those who can't.
> 
> Following http://tinyurl.com/2o5bld this should not be too hard I guess.
> Even for people (like me for instance) that have never played with
> branches in their own work (ok I have an advantage : I read the book)
> 
>> I'm gonna assume you understand the concepts I tried to describe
> above. It's dinner time now.
>> Ultimately, the concepts involve "maximizing concurrency". It won't be
> good if I find myself
>> limiting my rate/size of progress just so I don't "lose control" or
> lose sight of OFBiz trunk. I
>> just moved ahead at full speed, all the while being confident that
> OFBiz trunk will always be
>> mergeable into my SVN. The question is whether the OFBiz SVN is
> similarly confident about merging
>> our mad-cap-paced work into OFBiz trunk.
> 
> Yes I understand your POV. It stays that merging your change might be a
> challenge. And I'm not sure who will want to take it or rather have
> enough "free" time to do it.  Explaining clearly what these changes
> might bring to OFBiz (at the businnes and technical levels) would surely
> be a *1st step* in this direction.
> 
> Please, don't misunderstand me. Here, I'm trying to find a way to be
> able to merge your changes because I'm sure they are worth it.
> 
> Also remember this discussion we had with Chris (and others) about
> "joint work" and licence. This is perhaps the worse issue in your case !
> You may Googlize or use Nabble if you need explanations...
> 
> Jacques
> 
>> Jonathon
>>
>> Jacques Le Roux wrote:
>>> Jonathon,
>>>
>>> I don't want to be agressive or let you thing that I like to make
>>> "off-tangent" remarks. Here is what I think (I can't tell that
> facts):
>>> 1. I'm sure you might be able to be a great help for the community.
>>> 2. I better understand now why you'd like to have an "open" branch,
>>> correct me if I'm wrong
>>>     a. You have your own branch(es) of OFBiz
>>>     b. Not using our standard strategy (moving with the community,
> not
>>> alone) you "losed" the control about the changes you made
> respectively
>>> to the OFBiz trunk
>>>     c. This is not a problem for you (your branch is a fork but good
> for
>>> you)
>>>     d. You don't have time to extract your changes atomically but
> with a
>>> huge patch (unusable by commiters)
>>> 3. So your only solution to have your changes in the trunk is for us
> to
>>> open a branch for you
>>>
>>> Okay I'm a bit rude but you forced me and that's really what I
> think.
>>> Of course I'm open to discussion, you may also pass by my comments.
>>>
>>> Sorry and good luck
>>>
>>> Jacques
>>>
>>> ----- Message d'origine ----- 
>>> De : "Jonathon -- Improov" <jo...@improov.com>
>>> À : <de...@ofbiz.apache.org>
>>> Envoyé : dimanche 22 avril 2007 04:21
>>> Objet : Re: Ofbiz Contribution Proposal
>>>
>>>
>>>> Tim,
>>>>
>>>> I've already taken those "first steps" long ago. Like I said, I
> don't
>>> know which Jira "feature
>>>> requests" are not reviewed; I only know those I have merged into my
>>> own SVN. I really don't have
>>>> time to send up itemized or clearly demarcated patches.
>>>>
>>>> Many patches I grabbed from folks (sorry I did it so fast, I don't
>>> even know who), they work. Some
>>>> require streamlining mainly to match OFBiz coding standards and
> such,
>>> but still they do work. By
>>>> now, radical patches (like those from Chris Howes?) have gone
> through
>>> merging, and have even taken
>>>> a life (progressed) of their own. That's why I can't tell you
> "which
>>> Jira issues", because my
>>>> "private Jira store", so to speak, has "moved on". If I can do this
>>> aggressively merging without
>>>> problems (please use branches for sanity's sake), I am assuming the
>>> community of 400 here can do
>>>> the same, if not better. (And I'm guessing a good majority of this
> 400
>>> might just be doing what I
>>>> am doing, and OFBiz is none the better for it.)
>>>>
>>>> For now, let's just all do what we're good at, and keep at it.
> Maybe
>>> some day, I can submit a
>>>> gigantic patch and it will somehow translate into a bigger better
>>> OFBiz. For now, I can't help but
>>>> leech off of OFBiz, every single update, but still can't feed the
>>> whole sum back to OFBiz. Tough
>>>> on my conscience, but something I'll have to live with.
>>>>
>>>> By the way, I have no idea what some folks here are intending to
>>> achieve with some off-tangent
>>>> remarks. If it's "status quo" they want (in relation to me and "my"
>>> patches, ie), they've got it.
>>>> If you can understand what I'm doing in my own computers (with
> OFBiz
>>> and radical patches), that's
>>>> good and you may do the same good(?) thing in time. If not, I may
>>> change my bad(?) tactics over
>>>> time. Either way, let's just get back to what we're good at.
>>>>
>>>> Jonathon
>>>>
>>>> Tim Ruppert wrote:
>>>>> Jonathon - as has always been the case - the role of reviewing
>>> "complex"
>>>>> patches does not fall strictly on the committers - it falls on the
>>>>> entire community.  The committers then have the role of putting
> the
>>> code
>>>>> into the trunk.
>>>>>
>>>>> If you are so concerned that valid works are not being put back
> into
>>> the
>>>>> trunk aggressively enough (which I think that everyone who spends
>>> time
>>>>> over here would agree), could you try the proactive approach of
>>> looking
>>>>> at more patches and letting the community know which ones you
> think
>>> are
>>>>> tested well enough and offer enough value to go back into the
> trunk?
>>>>> That would be a GREAT first step and a very nice change of pace
> from
>>> the
>>>>> aggressive tone you seem to think is appropriate.
>>>>>
>>>>> Cheers,
>>>>> Tim
>>>>> --
>>>>> Tim Ruppert
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> o:801.649.6594
>>>>> f:801.649.6595
>>>>>
>>>>>
>>>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>>> "We" do not now, nor have we ever, turned away a contribution
>>> because it
>>>>>>> was complex.
>>>>>> Very well, I'll just use the word "you" then. I take it that you
> do
>>>>>> not turn away contributions because they were complex.
>>>>>>
>>>>>> The question from me would be whether you do or do not turn away,
>>>>>> knowingly or not, contributions that are valid but too complex
> for
>>>>>> review. It's not rhetorical, but you're free to do your own
>>>>>> sanity/verification checks on that supposed phenomenon and deem
> it
>>>>>> rhetorical or invalid.
>>>>>>
>>>>>>> Could you do us all a big favor Jonathon? Your comments seem to
>>> be
>>>>>>> fairly consistent along these lines. I think what would be
>>> helpful to
>>>>>>> you, and to anyone reading and agreeing with your comments, is
> to
>>> step
>>>>>>> back and try to explain why things are the way they are. Feel
>>> free to
>>>>>>> share that with the group for a sanity check if you'd like.
>>>>>> I'm not so sure of the "why" of things, but am only more certain
> of
>>>>>> the "what" of things. Things are the way they are, no matter how
> we
>>>>>> interpret the "why".
>>>>>>
>>>>>> So, for now, I continue to merge in (to my own SVN) several
>>>>>> contributions that are deemed too difficult to review/merge by
> the
>>>>>> committers. I continue to keep such enhancements in step with
>>> updates
>>>>>> from OFBiz trunk. And I continue in my failure(?) to feed such
>>>>>> "compatibilized/merged" enhancements back to OFBiz trunk even
>>> though
>>>>>> they really are the same license.
>>>>>>
>>>>>> And the phenomenon of several of us (incompatible contributors?)
>>>>>> holding on to our own enhancements will continue. Some of us may
>>> not
>>>>>> know how to keep in step with OFBiz trunk updates; others may.
>>> Those
>>>>>> of us who can keep in step will continue to benefit from OFBiz
>>>>>> progress, but be unable to feed the benefit back to OFBiz. There
>>> will
>>>>>> still be enhancements out there that are kept away/apart from
>>> OFBiz.
>>>>>> That's the way of things? Or maybe not?
>>>>>>
>>>>>> I stand corrected. I think I am "helping" OFBiz in the wrong way.
>>> I'll
>>>>>> stop that. :) Thanks for reminding me.
>>>>>>
>>>>>> I was waiting to dump the loads of my enhancements into your
> trunk,
>>>>>> but I think I should take a sanity check for now. Anyway, there
>>> needs
>>>>>> to be at least one stabilizing branch (save point, so to speak)
>>> before
>>>>>> we can go full steam with the trunk. And there's still no such
>>> branch yet.
>>>>>> Jonathon
>>>>>>
>>>>>> David E. Jones wrote:
>>>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>>>>>>> We shouldn't turn away complex contributions anymore.
>>>>>>> "We" do not now, nor have we ever, turned away a contribution
>>> because
>>>>>>> it was complex.
>>>>>>>> I myself have loads of enhancements (mostly to widget module)
>>> that I
>>>>>>>> feel uneasy about releasing to the community, simply because of
>>> this
>>>>>>>> odd use of trunk: it's used like a slow-moving release branch
>>> that
>>>>>>>> is unable to handle introductions of radical enhancements.
>>>>>>>>
>>>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and
>>> focused
>>>>>>>> enough on achieving release-quality stability. It's the worst
> of
>>>>>>>> both worlds: it's not rapid enough to allow for radical
> progress,
>>>>>>>> and not calm and focused-on-cleaning-up enough to produce a
>>> stable
>>>>>>>> release for non-OFBiz developers.
>>>>>>> Could you do us all a big favor Jonathon? Your comments seem to
> be
>>>>>>> fairly consistent along these lines. I think what would be
> helpful
>>> to
>>>>>>> you, and to anyone reading and agreeing with your comments, is
> to
>>>>>>> step back and try to explain why things are the way they are.
> Feel
>>>>>>> free to share that with the group for a sanity check if you'd
>>> like.
>>>>>>> -David
>>>
> 
> 

Re: Post Branch Enhancements

[Jacques Le Roux <ja...@les7arts.com>]

Jonathon,

You should read other messages, then you w'd have seen Chris's about the
new thread. Ok not a big deal. ;o)

Happy that you did not feel my last message "rude" and that your answer
is understandable by me (I must aknowledge that sometimes you lost me).

Perhaps kepping the habit of using numbered points will help our
communication (we have to keep it as concise as possible), trying :

Seems that only the 3d point needs some comments, they are inline...


----- Message d'origine ----- 
De : "Jonathon -- Improov" <jo...@improov.com>
À : <de...@ofbiz.apache.org>
Envoyé : dimanche 22 avril 2007 12:27
Objet : Re: Ofbiz Contribution Proposal


> Jacques,
>
> You lost me. I don't see where you are (or were ever) rude.
>
>  > a. You have your own branch(es) of OFBiz
>
> Yes, I have multiple branches sometimes, which will stabilize and
collapse into a few (possibly 2
> or 3) branches, and then eventually come down to trunk.
>
> Usually, when I see a huge patch(es) I might like, I'll see many
branches popping up.
>
>  > b. Not using our standard strategy (moving with the community,
>  > not alone) you "losed" the control about the changes you made
>  > respectively to the OFBiz trunk
>
> Hmm. That didn't happen.
>
> The trick is to keep a record of exactly where you branched off, to
know how and which
> files/folders to do a diff. Of course, you'll need to know which
direction to do the diff-patch.
>
>  > c. This is not a problem for you (your branch is a fork but good
>  > for you)
>
> If my branch isn't kept in step with OFBiz trunk, that's not ok for
me. The OFBiz trunk is
> constantly getting updates and bugfixes. Like I said, the "loss of
control" didn't happen. I am
> still in step with OFBiz trunk. Only issue I have is that the OFBiz
trunk can't keep in step with
> my own updates, which is fine by me if I really don't mind kicking
back and relaxing after
> finishing my own work.
>
>  > d. You don't have time to extract your changes atomically but
>  > with a huge patch (unusable by commiters)
>
> You're right on this count. Due to the way I perform wholesale
aggressive merges (to bring in big
> enhancements), my commits are not small. They are quite mostly large
and wide in scope. I perform
> such wholesale merges, then somehow systematically pick off all
incompatibilities.
>
> Hence, I can only feed large patches to the community, not atomic ones
like "Added feature A" or
> "Fixed bug B".
>
>  > 3. So your only solution to have your changes in the trunk is for
us to
>  > open a branch for you
>
> No, the solution is for myself to give you a patch that will bring 2
things together: the latest
> of OFBiz and the latest of my work. I can tell you that I've tested
this patch, but it's really up
> to the community to trust me.
>
> On your part, the solution would be to just dump my patch into your
trunk. Or if you want to have
> a cautious look-see first, you could open a new branch just to test
out my patch. This
> "exploratory/probationary" branch will be very short-lived, possibly
2-3 updates in the timeline.
> After the few updates, you can decide:
>
> a. My patch is playing well with the latest of OFBiz, and you merge it
into
>     trunk.
>
> OR
>
> b. My patch still has too many incompatibilities with OFBiz, and you
discard
>     it.

To be able to test your changes it'd be really better to at least have
an idea of the features that are added (or withdrawed f any). If they
are many changes and we don't know which they are, just funding our
reviewing work from a diff might be a nightmare.


> As you can see, the bulk of the work is on my part, in "bringing the
latest of OFBiz and my work
> together". The fact that I already have the latest of OFBiz playing
with my enhancements is
> already more than half the work done.
>
> Most folks I come across don't know how to do that part. I was
suggesting that someone among us,
> someone comfortable with version control adventures, perform that
merge for those who can't.

Following http://tinyurl.com/2o5bld this should not be too hard I guess.
Even for people (like me for instance) that have never played with
branches in their own work (ok I have an advantage : I read the book)

> I'm gonna assume you understand the concepts I tried to describe
above. It's dinner time now.
>
> Ultimately, the concepts involve "maximizing concurrency". It won't be
good if I find myself
> limiting my rate/size of progress just so I don't "lose control" or
lose sight of OFBiz trunk. I
> just moved ahead at full speed, all the while being confident that
OFBiz trunk will always be
> mergeable into my SVN. The question is whether the OFBiz SVN is
similarly confident about merging
> our mad-cap-paced work into OFBiz trunk.

Yes I understand your POV. It stays that merging your change might be a
challenge. And I'm not sure who will want to take it or rather have
enough "free" time to do it.  Explaining clearly what these changes
might bring to OFBiz (at the businnes and technical levels) would surely
be a *1st step* in this direction.

Please, don't misunderstand me. Here, I'm trying to find a way to be
able to merge your changes because I'm sure they are worth it.

Also remember this discussion we had with Chris (and others) about
"joint work" and licence. This is perhaps the worse issue in your case !
You may Googlize or use Nabble if you need explanations...

Jacques

> Jonathon
>
> Jacques Le Roux wrote:
> > Jonathon,
> >
> > I don't want to be agressive or let you thing that I like to make
> > "off-tangent" remarks. Here is what I think (I can't tell that
facts):
> >
> > 1. I'm sure you might be able to be a great help for the community.
> > 2. I better understand now why you'd like to have an "open" branch,
> > correct me if I'm wrong
> >     a. You have your own branch(es) of OFBiz
> >     b. Not using our standard strategy (moving with the community,
not
> > alone) you "losed" the control about the changes you made
respectively
> > to the OFBiz trunk
> >     c. This is not a problem for you (your branch is a fork but good
for
> > you)
> >     d. You don't have time to extract your changes atomically but
with a
> > huge patch (unusable by commiters)
> > 3. So your only solution to have your changes in the trunk is for us
to
> > open a branch for you
> >
> > Okay I'm a bit rude but you forced me and that's really what I
think.
> > Of course I'm open to discussion, you may also pass by my comments.
> >
> > Sorry and good luck
> >
> > Jacques
> >
> > ----- Message d'origine ----- 
> > De : "Jonathon -- Improov" <jo...@improov.com>
> > À : <de...@ofbiz.apache.org>
> > Envoyé : dimanche 22 avril 2007 04:21
> > Objet : Re: Ofbiz Contribution Proposal
> >
> >
> >> Tim,
> >>
> >> I've already taken those "first steps" long ago. Like I said, I
don't
> > know which Jira "feature
> >> requests" are not reviewed; I only know those I have merged into my
> > own SVN. I really don't have
> >> time to send up itemized or clearly demarcated patches.
> >>
> >> Many patches I grabbed from folks (sorry I did it so fast, I don't
> > even know who), they work. Some
> >> require streamlining mainly to match OFBiz coding standards and
such,
> > but still they do work. By
> >> now, radical patches (like those from Chris Howes?) have gone
through
> > merging, and have even taken
> >> a life (progressed) of their own. That's why I can't tell you
"which
> > Jira issues", because my
> >> "private Jira store", so to speak, has "moved on". If I can do this
> > aggressively merging without
> >> problems (please use branches for sanity's sake), I am assuming the
> > community of 400 here can do
> >> the same, if not better. (And I'm guessing a good majority of this
400
> > might just be doing what I
> >> am doing, and OFBiz is none the better for it.)
> >>
> >> For now, let's just all do what we're good at, and keep at it.
Maybe
> > some day, I can submit a
> >> gigantic patch and it will somehow translate into a bigger better
> > OFBiz. For now, I can't help but
> >> leech off of OFBiz, every single update, but still can't feed the
> > whole sum back to OFBiz. Tough
> >> on my conscience, but something I'll have to live with.
> >>
> >> By the way, I have no idea what some folks here are intending to
> > achieve with some off-tangent
> >> remarks. If it's "status quo" they want (in relation to me and "my"
> > patches, ie), they've got it.
> >> If you can understand what I'm doing in my own computers (with
OFBiz
> > and radical patches), that's
> >> good and you may do the same good(?) thing in time. If not, I may
> > change my bad(?) tactics over
> >> time. Either way, let's just get back to what we're good at.
> >>
> >> Jonathon
> >>
> >> Tim Ruppert wrote:
> >>> Jonathon - as has always been the case - the role of reviewing
> > "complex"
> >>> patches does not fall strictly on the committers - it falls on the
> >>> entire community.  The committers then have the role of putting
the
> > code
> >>> into the trunk.
> >>>
> >>> If you are so concerned that valid works are not being put back
into
> > the
> >>> trunk aggressively enough (which I think that everyone who spends
> > time
> >>> over here would agree), could you try the proactive approach of
> > looking
> >>> at more patches and letting the community know which ones you
think
> > are
> >>> tested well enough and offer enough value to go back into the
trunk?
> >>> That would be a GREAT first step and a very nice change of pace
from
> > the
> >>> aggressive tone you seem to think is appropriate.
> >>>
> >>> Cheers,
> >>> Tim
> >>> --
> >>> Tim Ruppert
> >>> HotWax Media
> >>> http://www.hotwaxmedia.com
> >>>
> >>> o:801.649.6594
> >>> f:801.649.6595
> >>>
> >>>
> >>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
> >>>
> >>>> David,
> >>>>
> >>>>> "We" do not now, nor have we ever, turned away a contribution
> > because it
> >>>>> was complex.
> >>>> Very well, I'll just use the word "you" then. I take it that you
do
> >>>> not turn away contributions because they were complex.
> >>>>
> >>>> The question from me would be whether you do or do not turn away,
> >>>> knowingly or not, contributions that are valid but too complex
for
> >>>> review. It's not rhetorical, but you're free to do your own
> >>>> sanity/verification checks on that supposed phenomenon and deem
it
> >>>> rhetorical or invalid.
> >>>>
> >>>>> Could you do us all a big favor Jonathon? Your comments seem to
> > be
> >>>>> fairly consistent along these lines. I think what would be
> > helpful to
> >>>>> you, and to anyone reading and agreeing with your comments, is
to
> > step
> >>>>> back and try to explain why things are the way they are. Feel
> > free to
> >>>>> share that with the group for a sanity check if you'd like.
> >>>> I'm not so sure of the "why" of things, but am only more certain
of
> >>>> the "what" of things. Things are the way they are, no matter how
we
> >>>> interpret the "why".
> >>>>
> >>>> So, for now, I continue to merge in (to my own SVN) several
> >>>> contributions that are deemed too difficult to review/merge by
the
> >>>> committers. I continue to keep such enhancements in step with
> > updates
> >>>> from OFBiz trunk. And I continue in my failure(?) to feed such
> >>>> "compatibilized/merged" enhancements back to OFBiz trunk even
> > though
> >>>> they really are the same license.
> >>>>
> >>>> And the phenomenon of several of us (incompatible contributors?)
> >>>> holding on to our own enhancements will continue. Some of us may
> > not
> >>>> know how to keep in step with OFBiz trunk updates; others may.
> > Those
> >>>> of us who can keep in step will continue to benefit from OFBiz
> >>>> progress, but be unable to feed the benefit back to OFBiz. There
> > will
> >>>> still be enhancements out there that are kept away/apart from
> > OFBiz.
> >>>> That's the way of things? Or maybe not?
> >>>>
> >>>> I stand corrected. I think I am "helping" OFBiz in the wrong way.
> > I'll
> >>>> stop that. :) Thanks for reminding me.
> >>>>
> >>>> I was waiting to dump the loads of my enhancements into your
trunk,
> >>>> but I think I should take a sanity check for now. Anyway, there
> > needs
> >>>> to be at least one stabilizing branch (save point, so to speak)
> > before
> >>>> we can go full steam with the trunk. And there's still no such
> > branch yet.
> >>>> Jonathon
> >>>>
> >>>> David E. Jones wrote:
> >>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> >>>>>> We shouldn't turn away complex contributions anymore.
> >>>>> "We" do not now, nor have we ever, turned away a contribution
> > because
> >>>>> it was complex.
> >>>>>> I myself have loads of enhancements (mostly to widget module)
> > that I
> >>>>>> feel uneasy about releasing to the community, simply because of
> > this
> >>>>>> odd use of trunk: it's used like a slow-moving release branch
> > that
> >>>>>> is unable to handle introductions of radical enhancements.
> >>>>>>
> >>>>>> Yet, this somewhat slow-moving trunk isn't still enough and
> > focused
> >>>>>> enough on achieving release-quality stability. It's the worst
of
> >>>>>> both worlds: it's not rapid enough to allow for radical
progress,
> >>>>>> and not calm and focused-on-cleaning-up enough to produce a
> > stable
> >>>>>> release for non-OFBiz developers.
> >>>>> Could you do us all a big favor Jonathon? Your comments seem to
be
> >>>>> fairly consistent along these lines. I think what would be
helpful
> > to
> >>>>> you, and to anyone reading and agreeing with your comments, is
to
> >>>>> step back and try to explain why things are the way they are.
Feel
> >>>>> free to share that with the group for a sanity check if you'd
> > like.
> >>>>> -David
> >
> >

Re: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Jacques,

You lost me. I don't see where you are (or were ever) rude.

 > a. You have your own branch(es) of OFBiz

Yes, I have multiple branches sometimes, which will stabilize and collapse into a few (possibly 2 
or 3) branches, and then eventually come down to trunk.

Usually, when I see a huge patch(es) I might like, I'll see many branches popping up.

 > b. Not using our standard strategy (moving with the community,
 > not alone) you "losed" the control about the changes you made
 > respectively to the OFBiz trunk

Hmm. That didn't happen.

The trick is to keep a record of exactly where you branched off, to know how and which 
files/folders to do a diff. Of course, you'll need to know which direction to do the diff-patch.

 > c. This is not a problem for you (your branch is a fork but good
 > for you)

If my branch isn't kept in step with OFBiz trunk, that's not ok for me. The OFBiz trunk is 
constantly getting updates and bugfixes. Like I said, the "loss of control" didn't happen. I am 
still in step with OFBiz trunk. Only issue I have is that the OFBiz trunk can't keep in step with 
my own updates, which is fine by me if I really don't mind kicking back and relaxing after 
finishing my own work.

 > d. You don't have time to extract your changes atomically but
 > with a huge patch (unusable by commiters)

You're right on this count. Due to the way I perform wholesale aggressive merges (to bring in big 
enhancements), my commits are not small. They are quite mostly large and wide in scope. I perform 
such wholesale merges, then somehow systematically pick off all incompatibilities.

Hence, I can only feed large patches to the community, not atomic ones like "Added feature A" or 
"Fixed bug B".

 > 3. So your only solution to have your changes in the trunk is for us to
 > open a branch for you

No, the solution is for myself to give you a patch that will bring 2 things together: the latest 
of OFBiz and the latest of my work. I can tell you that I've tested this patch, but it's really up 
to the community to trust me.

On your part, the solution would be to just dump my patch into your trunk. Or if you want to have 
a cautious look-see first, you could open a new branch just to test out my patch. This 
"exploratory/probationary" branch will be very short-lived, possibly 2-3 updates in the timeline. 
After the few updates, you can decide:

a. My patch is playing well with the latest of OFBiz, and you merge it into
    trunk.

OR

b. My patch still has too many incompatibilities with OFBiz, and you discard
    it.

As you can see, the bulk of the work is on my part, in "bringing the latest of OFBiz and my work 
together". The fact that I already have the latest of OFBiz playing with my enhancements is 
already more than half the work done.

Most folks I come across don't know how to do that part. I was suggesting that someone among us, 
someone comfortable with version control adventures, perform that merge for those who can't.

I'm gonna assume you understand the concepts I tried to describe above. It's dinner time now.

Ultimately, the concepts involve "maximizing concurrency". It won't be good if I find myself 
limiting my rate/size of progress just so I don't "lose control" or lose sight of OFBiz trunk. I 
just moved ahead at full speed, all the while being confident that OFBiz trunk will always be 
mergeable into my SVN. The question is whether the OFBiz SVN is similarly confident about merging 
our mad-cap-paced work into OFBiz trunk.

Jonathon

Jacques Le Roux wrote:
> Jonathon,
> 
> I don't want to be agressive or let you thing that I like to make
> "off-tangent" remarks. Here is what I think (I can't tell that facts):
> 
> 1. I'm sure you might be able to be a great help for the community.
> 2. I better understand now why you'd like to have an "open" branch,
> correct me if I'm wrong
>     a. You have your own branch(es) of OFBiz
>     b. Not using our standard strategy (moving with the community, not
> alone) you "losed" the control about the changes you made respectively
> to the OFBiz trunk
>     c. This is not a problem for you (your branch is a fork but good for
> you)
>     d. You don't have time to extract your changes atomically but with a
> huge patch (unusable by commiters)
> 3. So your only solution to have your changes in the trunk is for us to
> open a branch for you
> 
> Okay I'm a bit rude but you forced me and that's really what I think.
> Of course I'm open to discussion, you may also pass by my comments.
> 
> Sorry and good luck
> 
> Jacques
> 
> ----- Message d'origine ----- 
> De : "Jonathon -- Improov" <jo...@improov.com>
> À : <de...@ofbiz.apache.org>
> Envoyé : dimanche 22 avril 2007 04:21
> Objet : Re: Ofbiz Contribution Proposal
> 
> 
>> Tim,
>>
>> I've already taken those "first steps" long ago. Like I said, I don't
> know which Jira "feature
>> requests" are not reviewed; I only know those I have merged into my
> own SVN. I really don't have
>> time to send up itemized or clearly demarcated patches.
>>
>> Many patches I grabbed from folks (sorry I did it so fast, I don't
> even know who), they work. Some
>> require streamlining mainly to match OFBiz coding standards and such,
> but still they do work. By
>> now, radical patches (like those from Chris Howes?) have gone through
> merging, and have even taken
>> a life (progressed) of their own. That's why I can't tell you "which
> Jira issues", because my
>> "private Jira store", so to speak, has "moved on". If I can do this
> aggressively merging without
>> problems (please use branches for sanity's sake), I am assuming the
> community of 400 here can do
>> the same, if not better. (And I'm guessing a good majority of this 400
> might just be doing what I
>> am doing, and OFBiz is none the better for it.)
>>
>> For now, let's just all do what we're good at, and keep at it. Maybe
> some day, I can submit a
>> gigantic patch and it will somehow translate into a bigger better
> OFBiz. For now, I can't help but
>> leech off of OFBiz, every single update, but still can't feed the
> whole sum back to OFBiz. Tough
>> on my conscience, but something I'll have to live with.
>>
>> By the way, I have no idea what some folks here are intending to
> achieve with some off-tangent
>> remarks. If it's "status quo" they want (in relation to me and "my"
> patches, ie), they've got it.
>> If you can understand what I'm doing in my own computers (with OFBiz
> and radical patches), that's
>> good and you may do the same good(?) thing in time. If not, I may
> change my bad(?) tactics over
>> time. Either way, let's just get back to what we're good at.
>>
>> Jonathon
>>
>> Tim Ruppert wrote:
>>> Jonathon - as has always been the case - the role of reviewing
> "complex"
>>> patches does not fall strictly on the committers - it falls on the
>>> entire community.  The committers then have the role of putting the
> code
>>> into the trunk.
>>>
>>> If you are so concerned that valid works are not being put back into
> the
>>> trunk aggressively enough (which I think that everyone who spends
> time
>>> over here would agree), could you try the proactive approach of
> looking
>>> at more patches and letting the community know which ones you think
> are
>>> tested well enough and offer enough value to go back into the trunk?
>>> That would be a GREAT first step and a very nice change of pace from
> the
>>> aggressive tone you seem to think is appropriate.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>>
>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
>>>
>>>> David,
>>>>
>>>>> "We" do not now, nor have we ever, turned away a contribution
> because it
>>>>> was complex.
>>>> Very well, I'll just use the word "you" then. I take it that you do
>>>> not turn away contributions because they were complex.
>>>>
>>>> The question from me would be whether you do or do not turn away,
>>>> knowingly or not, contributions that are valid but too complex for
>>>> review. It's not rhetorical, but you're free to do your own
>>>> sanity/verification checks on that supposed phenomenon and deem it
>>>> rhetorical or invalid.
>>>>
>>>>> Could you do us all a big favor Jonathon? Your comments seem to
> be
>>>>> fairly consistent along these lines. I think what would be
> helpful to
>>>>> you, and to anyone reading and agreeing with your comments, is to
> step
>>>>> back and try to explain why things are the way they are. Feel
> free to
>>>>> share that with the group for a sanity check if you'd like.
>>>> I'm not so sure of the "why" of things, but am only more certain of
>>>> the "what" of things. Things are the way they are, no matter how we
>>>> interpret the "why".
>>>>
>>>> So, for now, I continue to merge in (to my own SVN) several
>>>> contributions that are deemed too difficult to review/merge by the
>>>> committers. I continue to keep such enhancements in step with
> updates
>>>> from OFBiz trunk. And I continue in my failure(?) to feed such
>>>> "compatibilized/merged" enhancements back to OFBiz trunk even
> though
>>>> they really are the same license.
>>>>
>>>> And the phenomenon of several of us (incompatible contributors?)
>>>> holding on to our own enhancements will continue. Some of us may
> not
>>>> know how to keep in step with OFBiz trunk updates; others may.
> Those
>>>> of us who can keep in step will continue to benefit from OFBiz
>>>> progress, but be unable to feed the benefit back to OFBiz. There
> will
>>>> still be enhancements out there that are kept away/apart from
> OFBiz.
>>>> That's the way of things? Or maybe not?
>>>>
>>>> I stand corrected. I think I am "helping" OFBiz in the wrong way.
> I'll
>>>> stop that. :) Thanks for reminding me.
>>>>
>>>> I was waiting to dump the loads of my enhancements into your trunk,
>>>> but I think I should take a sanity check for now. Anyway, there
> needs
>>>> to be at least one stabilizing branch (save point, so to speak)
> before
>>>> we can go full steam with the trunk. And there's still no such
> branch yet.
>>>> Jonathon
>>>>
>>>> David E. Jones wrote:
>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>>>>> We shouldn't turn away complex contributions anymore.
>>>>> "We" do not now, nor have we ever, turned away a contribution
> because
>>>>> it was complex.
>>>>>> I myself have loads of enhancements (mostly to widget module)
> that I
>>>>>> feel uneasy about releasing to the community, simply because of
> this
>>>>>> odd use of trunk: it's used like a slow-moving release branch
> that
>>>>>> is unable to handle introductions of radical enhancements.
>>>>>>
>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and
> focused
>>>>>> enough on achieving release-quality stability. It's the worst of
>>>>>> both worlds: it's not rapid enough to allow for radical progress,
>>>>>> and not calm and focused-on-cleaning-up enough to produce a
> stable
>>>>>> release for non-OFBiz developers.
>>>>> Could you do us all a big favor Jonathon? Your comments seem to be
>>>>> fairly consistent along these lines. I think what would be helpful
> to
>>>>> you, and to anyone reading and agreeing with your comments, is to
>>>>> step back and try to explain why things are the way they are. Feel
>>>>> free to share that with the group for a sanity check if you'd
> like.
>>>>> -David
> 
> 

Re: Ofbiz Contribution Proposal

[Jacques Le Roux <ja...@les7arts.com>]

Jonathon,

I don't want to be agressive or let you thing that I like to make
"off-tangent" remarks. Here is what I think (I can't tell that facts):

1. I'm sure you might be able to be a great help for the community.
2. I better understand now why you'd like to have an "open" branch,
correct me if I'm wrong
    a. You have your own branch(es) of OFBiz
    b. Not using our standard strategy (moving with the community, not
alone) you "losed" the control about the changes you made respectively
to the OFBiz trunk
    c. This is not a problem for you (your branch is a fork but good for
you)
    d. You don't have time to extract your changes atomically but with a
huge patch (unusable by commiters)
3. So your only solution to have your changes in the trunk is for us to
open a branch for you

Okay I'm a bit rude but you forced me and that's really what I think.
Of course I'm open to discussion, you may also pass by my comments.

Sorry and good luck

Jacques

----- Message d'origine ----- 
De : "Jonathon -- Improov" <jo...@improov.com>
À : <de...@ofbiz.apache.org>
Envoyé : dimanche 22 avril 2007 04:21
Objet : Re: Ofbiz Contribution Proposal


> Tim,
>
> I've already taken those "first steps" long ago. Like I said, I don't
know which Jira "feature
> requests" are not reviewed; I only know those I have merged into my
own SVN. I really don't have
> time to send up itemized or clearly demarcated patches.
>
> Many patches I grabbed from folks (sorry I did it so fast, I don't
even know who), they work. Some
> require streamlining mainly to match OFBiz coding standards and such,
but still they do work. By
> now, radical patches (like those from Chris Howes?) have gone through
merging, and have even taken
> a life (progressed) of their own. That's why I can't tell you "which
Jira issues", because my
> "private Jira store", so to speak, has "moved on". If I can do this
aggressively merging without
> problems (please use branches for sanity's sake), I am assuming the
community of 400 here can do
> the same, if not better. (And I'm guessing a good majority of this 400
might just be doing what I
> am doing, and OFBiz is none the better for it.)
>
> For now, let's just all do what we're good at, and keep at it. Maybe
some day, I can submit a
> gigantic patch and it will somehow translate into a bigger better
OFBiz. For now, I can't help but
> leech off of OFBiz, every single update, but still can't feed the
whole sum back to OFBiz. Tough
> on my conscience, but something I'll have to live with.
>
> By the way, I have no idea what some folks here are intending to
achieve with some off-tangent
> remarks. If it's "status quo" they want (in relation to me and "my"
patches, ie), they've got it.
>
> If you can understand what I'm doing in my own computers (with OFBiz
and radical patches), that's
> good and you may do the same good(?) thing in time. If not, I may
change my bad(?) tactics over
> time. Either way, let's just get back to what we're good at.
>
> Jonathon
>
> Tim Ruppert wrote:
> > Jonathon - as has always been the case - the role of reviewing
"complex"
> > patches does not fall strictly on the committers - it falls on the
> > entire community.  The committers then have the role of putting the
code
> > into the trunk.
> >
> > If you are so concerned that valid works are not being put back into
the
> > trunk aggressively enough (which I think that everyone who spends
time
> > over here would agree), could you try the proactive approach of
looking
> > at more patches and letting the community know which ones you think
are
> > tested well enough and offer enough value to go back into the trunk?
> > That would be a GREAT first step and a very nice change of pace from
the
> > aggressive tone you seem to think is appropriate.
> >
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> >
> > o:801.649.6594
> > f:801.649.6595
> >
> >
> > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
> >
> >> David,
> >>
> >> > "We" do not now, nor have we ever, turned away a contribution
because it
> >> > was complex.
> >>
> >> Very well, I'll just use the word "you" then. I take it that you do
> >> not turn away contributions because they were complex.
> >>
> >> The question from me would be whether you do or do not turn away,
> >> knowingly or not, contributions that are valid but too complex for
> >> review. It's not rhetorical, but you're free to do your own
> >> sanity/verification checks on that supposed phenomenon and deem it
> >> rhetorical or invalid.
> >>
> >> > Could you do us all a big favor Jonathon? Your comments seem to
be
> >> > fairly consistent along these lines. I think what would be
helpful to
> >> > you, and to anyone reading and agreeing with your comments, is to
step
> >> > back and try to explain why things are the way they are. Feel
free to
> >> > share that with the group for a sanity check if you'd like.
> >>
> >> I'm not so sure of the "why" of things, but am only more certain of
> >> the "what" of things. Things are the way they are, no matter how we
> >> interpret the "why".
> >>
> >> So, for now, I continue to merge in (to my own SVN) several
> >> contributions that are deemed too difficult to review/merge by the
> >> committers. I continue to keep such enhancements in step with
updates
> >> from OFBiz trunk. And I continue in my failure(?) to feed such
> >> "compatibilized/merged" enhancements back to OFBiz trunk even
though
> >> they really are the same license.
> >>
> >> And the phenomenon of several of us (incompatible contributors?)
> >> holding on to our own enhancements will continue. Some of us may
not
> >> know how to keep in step with OFBiz trunk updates; others may.
Those
> >> of us who can keep in step will continue to benefit from OFBiz
> >> progress, but be unable to feed the benefit back to OFBiz. There
will
> >> still be enhancements out there that are kept away/apart from
OFBiz.
> >> That's the way of things? Or maybe not?
> >>
> >> I stand corrected. I think I am "helping" OFBiz in the wrong way.
I'll
> >> stop that. :) Thanks for reminding me.
> >>
> >> I was waiting to dump the loads of my enhancements into your trunk,
> >> but I think I should take a sanity check for now. Anyway, there
needs
> >> to be at least one stabilizing branch (save point, so to speak)
before
> >> we can go full steam with the trunk. And there's still no such
branch yet.
> >>
> >> Jonathon
> >>
> >> David E. Jones wrote:
> >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> >>>> We shouldn't turn away complex contributions anymore.
> >>> "We" do not now, nor have we ever, turned away a contribution
because
> >>> it was complex.
> >>>> I myself have loads of enhancements (mostly to widget module)
that I
> >>>> feel uneasy about releasing to the community, simply because of
this
> >>>> odd use of trunk: it's used like a slow-moving release branch
that
> >>>> is unable to handle introductions of radical enhancements.
> >>>>
> >>>> Yet, this somewhat slow-moving trunk isn't still enough and
focused
> >>>> enough on achieving release-quality stability. It's the worst of
> >>>> both worlds: it's not rapid enough to allow for radical progress,
> >>>> and not calm and focused-on-cleaning-up enough to produce a
stable
> >>>> release for non-OFBiz developers.
> >>> Could you do us all a big favor Jonathon? Your comments seem to be
> >>> fairly consistent along these lines. I think what would be helpful
to
> >>> you, and to anyone reading and agreeing with your comments, is to
> >>> step back and try to explain why things are the way they are. Feel
> >>> free to share that with the group for a sanity check if you'd
like.
> >>> -David
> >>
> >

Re: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Tim,

I've already taken those "first steps" long ago. Like I said, I don't know which Jira "feature 
requests" are not reviewed; I only know those I have merged into my own SVN. I really don't have 
time to send up itemized or clearly demarcated patches.

Many patches I grabbed from folks (sorry I did it so fast, I don't even know who), they work. Some 
require streamlining mainly to match OFBiz coding standards and such, but still they do work. By 
now, radical patches (like those from Chris Howes?) have gone through merging, and have even taken 
a life (progressed) of their own. That's why I can't tell you "which Jira issues", because my 
"private Jira store", so to speak, has "moved on". If I can do this aggressively merging without 
problems (please use branches for sanity's sake), I am assuming the community of 400 here can do 
the same, if not better. (And I'm guessing a good majority of this 400 might just be doing what I 
am doing, and OFBiz is none the better for it.)

For now, let's just all do what we're good at, and keep at it. Maybe some day, I can submit a 
gigantic patch and it will somehow translate into a bigger better OFBiz. For now, I can't help but 
leech off of OFBiz, every single update, but still can't feed the whole sum back to OFBiz. Tough 
on my conscience, but something I'll have to live with.

By the way, I have no idea what some folks here are intending to achieve with some off-tangent 
remarks. If it's "status quo" they want (in relation to me and "my" patches, ie), they've got it.

If you can understand what I'm doing in my own computers (with OFBiz and radical patches), that's 
good and you may do the same good(?) thing in time. If not, I may change my bad(?) tactics over 
time. Either way, let's just get back to what we're good at.

Jonathon

Tim Ruppert wrote:
> Jonathon - as has always been the case - the role of reviewing "complex" 
> patches does not fall strictly on the committers - it falls on the 
> entire community.  The committers then have the role of putting the code 
> into the trunk. 
> 
> If you are so concerned that valid works are not being put back into the 
> trunk aggressively enough (which I think that everyone who spends time 
> over here would agree), could you try the proactive approach of looking 
> at more patches and letting the community know which ones you think are 
> tested well enough and offer enough value to go back into the trunk?  
> That would be a GREAT first step and a very nice change of pace from the 
> aggressive tone you seem to think is appropriate.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595
> 
> 
> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
> 
>> David,
>>
>> > "We" do not now, nor have we ever, turned away a contribution because it
>> > was complex.
>>
>> Very well, I'll just use the word "you" then. I take it that you do 
>> not turn away contributions because they were complex.
>>
>> The question from me would be whether you do or do not turn away, 
>> knowingly or not, contributions that are valid but too complex for 
>> review. It's not rhetorical, but you're free to do your own 
>> sanity/verification checks on that supposed phenomenon and deem it 
>> rhetorical or invalid.
>>
>> > Could you do us all a big favor Jonathon? Your comments seem to be
>> > fairly consistent along these lines. I think what would be helpful to
>> > you, and to anyone reading and agreeing with your comments, is to step
>> > back and try to explain why things are the way they are. Feel free to
>> > share that with the group for a sanity check if you'd like.
>>
>> I'm not so sure of the "why" of things, but am only more certain of 
>> the "what" of things. Things are the way they are, no matter how we 
>> interpret the "why".
>>
>> So, for now, I continue to merge in (to my own SVN) several 
>> contributions that are deemed too difficult to review/merge by the 
>> committers. I continue to keep such enhancements in step with updates 
>> from OFBiz trunk. And I continue in my failure(?) to feed such 
>> "compatibilized/merged" enhancements back to OFBiz trunk even though 
>> they really are the same license.
>>
>> And the phenomenon of several of us (incompatible contributors?) 
>> holding on to our own enhancements will continue. Some of us may not 
>> know how to keep in step with OFBiz trunk updates; others may. Those 
>> of us who can keep in step will continue to benefit from OFBiz 
>> progress, but be unable to feed the benefit back to OFBiz. There will 
>> still be enhancements out there that are kept away/apart from OFBiz. 
>> That's the way of things? Or maybe not?
>>
>> I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll 
>> stop that. :) Thanks for reminding me.
>>
>> I was waiting to dump the loads of my enhancements into your trunk, 
>> but I think I should take a sanity check for now. Anyway, there needs 
>> to be at least one stabilizing branch (save point, so to speak) before 
>> we can go full steam with the trunk. And there's still no such branch yet.
>>
>> Jonathon
>>
>> David E. Jones wrote:
>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>>> We shouldn't turn away complex contributions anymore.
>>> "We" do not now, nor have we ever, turned away a contribution because 
>>> it was complex.
>>>> I myself have loads of enhancements (mostly to widget module) that I 
>>>> feel uneasy about releasing to the community, simply because of this 
>>>> odd use of trunk: it's used like a slow-moving release branch that 
>>>> is unable to handle introductions of radical enhancements.
>>>>
>>>> Yet, this somewhat slow-moving trunk isn't still enough and focused 
>>>> enough on achieving release-quality stability. It's the worst of 
>>>> both worlds: it's not rapid enough to allow for radical progress, 
>>>> and not calm and focused-on-cleaning-up enough to produce a stable 
>>>> release for non-OFBiz developers.
>>> Could you do us all a big favor Jonathon? Your comments seem to be 
>>> fairly consistent along these lines. I think what would be helpful to 
>>> you, and to anyone reading and agreeing with your comments, is to 
>>> step back and try to explain why things are the way they are. Feel 
>>> free to share that with the group for a sanity check if you'd like.
>>> -David
>>
> 

Re: Ofbiz Contribution Proposal

[Jacques Le Roux <ja...@les7arts.com>]

I totally agree with Tim POV. Even I you don't want to become a commiter (yeah, they have some duties and they give some of their time for free) helping them to do their job is the best way to accelerate commiting. Especially if you have already tested things (means patches I guess) in you own code. I'm quite sure your help would be very valuable !

Jacques
  ----- Message d'origine ----- 
  De : Tim Ruppert 
  À : dev@ofbiz.apache.org 
  Envoyé : samedi 21 avril 2007 17:47
  Objet : Re: Ofbiz Contribution Proposal


  Jonathon - as has always been the case - the role of reviewing "complex" patches does not fall strictly on the committers - it falls on the entire community.  The committers then have the role of putting the code into the trunk. 


  If you are so concerned that valid works are not being put back into the trunk aggressively enough (which I think that everyone who spends time over here would agree), could you try the proactive approach of looking at more patches and letting the community know which ones you think are tested well enough and offer enough value to go back into the trunk?  That would be a GREAT first step and a very nice change of pace from the aggressive tone you seem to think is appropriate.



  Cheers,
  Tim
  --
  Tim Ruppert
  HotWax Media
  http://www.hotwaxmedia.com


  o:801.649.6594
  f:801.649.6595




  On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:


    David,


    > "We" do not now, nor have we ever, turned away a contribution because it
    > was complex.


    Very well, I'll just use the word "you" then. I take it that you do not turn away contributions because they were complex.


    The question from me would be whether you do or do not turn away, knowingly or not, contributions that are valid but too complex for review. It's not rhetorical, but you're free to do your own sanity/verification checks on that supposed phenomenon and deem it rhetorical or invalid.


    > Could you do us all a big favor Jonathon? Your comments seem to be
    > fairly consistent along these lines. I think what would be helpful to
    > you, and to anyone reading and agreeing with your comments, is to step
    > back and try to explain why things are the way they are. Feel free to
    > share that with the group for a sanity check if you'd like.


    I'm not so sure of the "why" of things, but am only more certain of the "what" of things. Things are the way they are, no matter how we interpret the "why".


    So, for now, I continue to merge in (to my own SVN) several contributions that are deemed too difficult to review/merge by the committers. I continue to keep such enhancements in step with updates from OFBiz trunk. And I continue in my failure(?) to feed such "compatibilized/merged" enhancements back to OFBiz trunk even though they really are the same license.


    And the phenomenon of several of us (incompatible contributors?) holding on to our own enhancements will continue. Some of us may not know how to keep in step with OFBiz trunk updates; others may. Those of us who can keep in step will continue to benefit from OFBiz progress, but be unable to feed the benefit back to OFBiz. There will still be enhancements out there that are kept away/apart from OFBiz. That's the way of things? Or maybe not?


    I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll stop that. :) Thanks for reminding me.


    I was waiting to dump the loads of my enhancements into your trunk, but I think I should take a sanity check for now. Anyway, there needs to be at least one stabilizing branch (save point, so to speak) before we can go full steam with the trunk. And there's still no such branch yet.


    Jonathon


    David E. Jones wrote:
      On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
        We shouldn't turn away complex contributions anymore.
      "We" do not now, nor have we ever, turned away a contribution because it was complex.
        I myself have loads of enhancements (mostly to widget module) that I feel uneasy about releasing to the community, simply because of this odd use of trunk: it's used like a slow-moving release branch that is unable to handle introductions of radical enhancements.


        Yet, this somewhat slow-moving trunk isn't still enough and focused enough on achieving release-quality stability. It's the worst of both worlds: it's not rapid enough to allow for radical progress, and not calm and focused-on-cleaning-up enough to produce a stable release for non-OFBiz developers.
      Could you do us all a big favor Jonathon? Your comments seem to be fairly consistent along these lines. I think what would be helpful to you, and to anyone reading and agreeing with your comments, is to step back and try to explain why things are the way they are. Feel free to share that with the group for a sanity check if you'd like.
      -David

Re: Ofbiz Contribution Proposal

[Tim Ruppert <ti...@hotwaxmedia.com>]

Jonathon - as has always been the case - the role of reviewing  
"complex" patches does not fall strictly on the committers - it falls  
on the entire community.  The committers then have the role of  
putting the code into the trunk.

If you are so concerned that valid works are not being put back into  
the trunk aggressively enough (which I think that everyone who spends  
time over here would agree), could you try the proactive approach of  
looking at more patches and letting the community know which ones you  
think are tested well enough and offer enough value to go back into  
the trunk?  That would be a GREAT first step and a very nice change  
of pace from the aggressive tone you seem to think is appropriate.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:

> David,
>
> > "We" do not now, nor have we ever, turned away a contribution  
> because it
> > was complex.
>
> Very well, I'll just use the word "you" then. I take it that you do  
> not turn away contributions because they were complex.
>
> The question from me would be whether you do or do not turn away,  
> knowingly or not, contributions that are valid but too complex for  
> review. It's not rhetorical, but you're free to do your own sanity/ 
> verification checks on that supposed phenomenon and deem it  
> rhetorical or invalid.
>
> > Could you do us all a big favor Jonathon? Your comments seem to be
> > fairly consistent along these lines. I think what would be  
> helpful to
> > you, and to anyone reading and agreeing with your comments, is to  
> step
> > back and try to explain why things are the way they are. Feel  
> free to
> > share that with the group for a sanity check if you'd like.
>
> I'm not so sure of the "why" of things, but am only more certain of  
> the "what" of things. Things are the way they are, no matter how we  
> interpret the "why".
>
> So, for now, I continue to merge in (to my own SVN) several  
> contributions that are deemed too difficult to review/merge by the  
> committers. I continue to keep such enhancements in step with  
> updates from OFBiz trunk. And I continue in my failure(?) to feed  
> such "compatibilized/merged" enhancements back to OFBiz trunk even  
> though they really are the same license.
>
> And the phenomenon of several of us (incompatible contributors?)  
> holding on to our own enhancements will continue. Some of us may  
> not know how to keep in step with OFBiz trunk updates; others may.  
> Those of us who can keep in step will continue to benefit from  
> OFBiz progress, but be unable to feed the benefit back to OFBiz.  
> There will still be enhancements out there that are kept away/apart  
> from OFBiz. That's the way of things? Or maybe not?
>
> I stand corrected. I think I am "helping" OFBiz in the wrong way.  
> I'll stop that. :) Thanks for reminding me.
>
> I was waiting to dump the loads of my enhancements into your trunk,  
> but I think I should take a sanity check for now. Anyway, there  
> needs to be at least one stabilizing branch (save point, so to  
> speak) before we can go full steam with the trunk. And there's  
> still no such branch yet.
>
> Jonathon
>
> David E. Jones wrote:
>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>> We shouldn't turn away complex contributions anymore.
>> "We" do not now, nor have we ever, turned away a contribution  
>> because it was complex.
>>> I myself have loads of enhancements (mostly to widget module)  
>>> that I feel uneasy about releasing to the community, simply  
>>> because of this odd use of trunk: it's used like a slow-moving  
>>> release branch that is unable to handle introductions of radical  
>>> enhancements.
>>>
>>> Yet, this somewhat slow-moving trunk isn't still enough and  
>>> focused enough on achieving release-quality stability. It's the  
>>> worst of both worlds: it's not rapid enough to allow for radical  
>>> progress, and not calm and focused-on-cleaning-up enough to  
>>> produce a stable release for non-OFBiz developers.
>> Could you do us all a big favor Jonathon? Your comments seem to be  
>> fairly consistent along these lines. I think what would be helpful  
>> to you, and to anyone reading and agreeing with your comments, is  
>> to step back and try to explain why things are the way they are.  
>> Feel free to share that with the group for a sanity check if you'd  
>> like.
>> -David
>

Re: Post Branch Enhancements (Re: Ofbiz Contribution Proposal)

[Jacopo Cappellato <ti...@sastau.it>]

Jonathon,

Jonathon -- Improov wrote:
> Chris,
> 
> I don't know offhand which enhancements (currently on Jira) are not 
> reviewed. I only know those I have with me.
> 

What are these enhancements? Are they in Jira?

> I feel we should never let newcomers (or even old timers) hear something 
> like "please dump your stuff in that corner, and we'll get to it in 
> time". No, not that we'd be rude. Just that we'd lose that contribution! 
> We're on the receiving end, so I suggest we start begging for the 
> contribution instead.
> 

Who said this? Jira is not a 'corner', it's the main (and only, for non 
committers) channel for accepting a contribution.

> Being reasonably experienced/adept with version control systems 
> (SVN/CVS), I can't see why we can't have someone perform a wholesale 
> merge (to resolve incompatibilities) on a "crazy, no holds barred branch".
> 

I think it's funny that, because you don't like Jira, you are proposing 
to make everyone a committer.

Jacopo

Re: Post Branch Enhancements (Re: Ofbiz Contribution Proposal)

[Jonathon -- Improov <jo...@improov.com>]

Chris,

I don't know offhand which enhancements (currently on Jira) are not reviewed. I only know those I 
have with me.

I feel we should never let newcomers (or even old timers) hear something like "please dump your 
stuff in that corner, and we'll get to it in time". No, not that we'd be rude. Just that we'd lose 
that contribution! We're on the receiving end, so I suggest we start begging for the contribution 
instead.

Being reasonably experienced/adept with version control systems (SVN/CVS), I can't see why we 
can't have someone perform a wholesale merge (to resolve incompatibilities) on a "crazy, no holds 
barred branch".

Then we may ask, "ok, so who's gonna test that crazy branch and deem it adequately 
compatilibized/merged to be patched back into trunk"? That's why I'm guessing that our 
(contributors') main motivation for donating codes is to have the latest and greatest of OFBiz 
work with our tested enhancements. The code contributor himself will start using that crazy 
branch, just to see his own enhancements working in tandem with the latest and greatest of OFBiz.

Jonathon

Chris Howe wrote:
> I sense this discussion may be hijacking Karl's thread, thus the
> subject change.  Karl's proposal looks very interesting and deserves
> its own thread.
> 
> <trying to turn this to constructive dialog>
> Jonathon, which enhancement are you speaking of that hasn't had the
> opportunity to be reviewed sufficiently?  
> 
> As soon as the formal vote concludes on the branch, I'm sure there will
> be a lot of dialog about direction and features and approaches to bug
> fixes in the coming days and weeks.  
> 
> If someone replies to this, please cut of the (was...) in the subject
> 
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
>> David,
>>
>>  > "We" do not now, nor have we ever, turned away a contribution
>> because it
>>  > was complex.
>>
>> Very well, I'll just use the word "you" then. I take it that you do
>> not turn away contributions 
>> because they were complex.
>>
>> The question from me would be whether you do or do not turn away,
>> knowingly or not, contributions 
>> that are valid but too complex for review. It's not rhetorical, but
>> you're free to do your own 
>> sanity/verification checks on that supposed phenomenon and deem it
>> rhetorical or invalid.
>>
>>  > Could you do us all a big favor Jonathon? Your comments seem to be
>>  > fairly consistent along these lines. I think what would be helpful
>> to
>>  > you, and to anyone reading and agreeing with your comments, is to
>> step
>>  > back and try to explain why things are the way they are. Feel free
>> to
>>  > share that with the group for a sanity check if you'd like.
>>
>> I'm not so sure of the "why" of things, but am only more certain of
>> the "what" of things. Things 
>> are the way they are, no matter how we interpret the "why".
>>
>> So, for now, I continue to merge in (to my own SVN) several
>> contributions that are deemed too 
>> difficult to review/merge by the committers. I continue to keep such
>> enhancements in step with 
>> updates from OFBiz trunk. And I continue in my failure(?) to feed
>> such "compatibilized/merged" 
>> enhancements back to OFBiz trunk even though they really are the same
>> license.
>>
>> And the phenomenon of several of us (incompatible contributors?)
>> holding on to our own 
>> enhancements will continue. Some of us may not know how to keep in
>> step with OFBiz trunk updates; 
>> others may. Those of us who can keep in step will continue to benefit
>> from OFBiz progress, but be 
>> unable to feed the benefit back to OFBiz. There will still be
>> enhancements out there that are kept 
>> away/apart from OFBiz. That's the way of things? Or maybe not?
>>
>> I stand corrected. I think I am "helping" OFBiz in the wrong way.
>> I'll stop that. :) Thanks for 
>> reminding me.
>>
>> I was waiting to dump the loads of my enhancements into your trunk,
>> but I think I should take a 
>> sanity check for now. Anyway, there needs to be at least one
>> stabilizing branch (save point, so to 
>> speak) before we can go full steam with the trunk. And there's still
>> no such branch yet.
>>
>> Jonathon
>>
>> David E. Jones wrote:
>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
>>>
>>>> We shouldn't turn away complex contributions anymore.
>>> "We" do not now, nor have we ever, turned away a contribution
>> because it 
>>> was complex.
>>>
>>>> I myself have loads of enhancements (mostly to widget module) that
>> I 
>>>> feel uneasy about releasing to the community, simply because of
>> this 
>>>> odd use of trunk: it's used like a slow-moving release branch that
>> is 
>>>> unable to handle introductions of radical enhancements.
>>>>
>>>> Yet, this somewhat slow-moving trunk isn't still enough and
>> focused 
>>>> enough on achieving release-quality stability. It's the worst of
>> both 
>>>> worlds: it's not rapid enough to allow for radical progress, and
>> not 
>>>> calm and focused-on-cleaning-up enough to produce a stable release
>> for 
>>>> non-OFBiz developers.
>>> Could you do us all a big favor Jonathon? Your comments seem to be 
>>> fairly consistent along these lines. I think what would be helpful
>> to 
>>> you, and to anyone reading and agreeing with your comments, is to
>> step 
>>> back and try to explain why things are the way they are. Feel free
>> to 
>>> share that with the group for a sanity check if you'd like.
>>>
>>> -David
>>>
>>>
>>
> 
> 

Post Branch Enhancements (was Re: Ofbiz Contribution Proposal)

[Chris Howe <cj...@yahoo.com>]

I sense this discussion may be hijacking Karl's thread, thus the
subject change.  Karl's proposal looks very interesting and deserves
its own thread.

<trying to turn this to constructive dialog>
Jonathon, which enhancement are you speaking of that hasn't had the
opportunity to be reviewed sufficiently?  

As soon as the formal vote concludes on the branch, I'm sure there will
be a lot of dialog about direction and features and approaches to bug
fixes in the coming days and weeks.  

If someone replies to this, please cut of the (was...) in the subject


--- Jonathon -- Improov <jo...@improov.com> wrote:

> David,
> 
>  > "We" do not now, nor have we ever, turned away a contribution
> because it
>  > was complex.
> 
> Very well, I'll just use the word "you" then. I take it that you do
> not turn away contributions 
> because they were complex.
> 
> The question from me would be whether you do or do not turn away,
> knowingly or not, contributions 
> that are valid but too complex for review. It's not rhetorical, but
> you're free to do your own 
> sanity/verification checks on that supposed phenomenon and deem it
> rhetorical or invalid.
> 
>  > Could you do us all a big favor Jonathon? Your comments seem to be
>  > fairly consistent along these lines. I think what would be helpful
> to
>  > you, and to anyone reading and agreeing with your comments, is to
> step
>  > back and try to explain why things are the way they are. Feel free
> to
>  > share that with the group for a sanity check if you'd like.
> 
> I'm not so sure of the "why" of things, but am only more certain of
> the "what" of things. Things 
> are the way they are, no matter how we interpret the "why".
> 
> So, for now, I continue to merge in (to my own SVN) several
> contributions that are deemed too 
> difficult to review/merge by the committers. I continue to keep such
> enhancements in step with 
> updates from OFBiz trunk. And I continue in my failure(?) to feed
> such "compatibilized/merged" 
> enhancements back to OFBiz trunk even though they really are the same
> license.
> 
> And the phenomenon of several of us (incompatible contributors?)
> holding on to our own 
> enhancements will continue. Some of us may not know how to keep in
> step with OFBiz trunk updates; 
> others may. Those of us who can keep in step will continue to benefit
> from OFBiz progress, but be 
> unable to feed the benefit back to OFBiz. There will still be
> enhancements out there that are kept 
> away/apart from OFBiz. That's the way of things? Or maybe not?
> 
> I stand corrected. I think I am "helping" OFBiz in the wrong way.
> I'll stop that. :) Thanks for 
> reminding me.
> 
> I was waiting to dump the loads of my enhancements into your trunk,
> but I think I should take a 
> sanity check for now. Anyway, there needs to be at least one
> stabilizing branch (save point, so to 
> speak) before we can go full steam with the trunk. And there's still
> no such branch yet.
> 
> Jonathon
> 
> David E. Jones wrote:
> > 
> > On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> > 
> >> We shouldn't turn away complex contributions anymore.
> > 
> > "We" do not now, nor have we ever, turned away a contribution
> because it 
> > was complex.
> > 
> >> I myself have loads of enhancements (mostly to widget module) that
> I 
> >> feel uneasy about releasing to the community, simply because of
> this 
> >> odd use of trunk: it's used like a slow-moving release branch that
> is 
> >> unable to handle introductions of radical enhancements.
> >>
> >> Yet, this somewhat slow-moving trunk isn't still enough and
> focused 
> >> enough on achieving release-quality stability. It's the worst of
> both 
> >> worlds: it's not rapid enough to allow for radical progress, and
> not 
> >> calm and focused-on-cleaning-up enough to produce a stable release
> for 
> >> non-OFBiz developers.
> > 
> > Could you do us all a big favor Jonathon? Your comments seem to be 
> > fairly consistent along these lines. I think what would be helpful
> to 
> > you, and to anyone reading and agreeing with your comments, is to
> step 
> > back and try to explain why things are the way they are. Feel free
> to 
> > share that with the group for a sanity check if you'd like.
> > 
> > -David
> > 
> > 
> 
> 

Re: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

David,

 > "We" do not now, nor have we ever, turned away a contribution because it
 > was complex.

Very well, I'll just use the word "you" then. I take it that you do not turn away contributions 
because they were complex.

The question from me would be whether you do or do not turn away, knowingly or not, contributions 
that are valid but too complex for review. It's not rhetorical, but you're free to do your own 
sanity/verification checks on that supposed phenomenon and deem it rhetorical or invalid.

 > Could you do us all a big favor Jonathon? Your comments seem to be
 > fairly consistent along these lines. I think what would be helpful to
 > you, and to anyone reading and agreeing with your comments, is to step
 > back and try to explain why things are the way they are. Feel free to
 > share that with the group for a sanity check if you'd like.

I'm not so sure of the "why" of things, but am only more certain of the "what" of things. Things 
are the way they are, no matter how we interpret the "why".

So, for now, I continue to merge in (to my own SVN) several contributions that are deemed too 
difficult to review/merge by the committers. I continue to keep such enhancements in step with 
updates from OFBiz trunk. And I continue in my failure(?) to feed such "compatibilized/merged" 
enhancements back to OFBiz trunk even though they really are the same license.

And the phenomenon of several of us (incompatible contributors?) holding on to our own 
enhancements will continue. Some of us may not know how to keep in step with OFBiz trunk updates; 
others may. Those of us who can keep in step will continue to benefit from OFBiz progress, but be 
unable to feed the benefit back to OFBiz. There will still be enhancements out there that are kept 
away/apart from OFBiz. That's the way of things? Or maybe not?

I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll stop that. :) Thanks for 
reminding me.

I was waiting to dump the loads of my enhancements into your trunk, but I think I should take a 
sanity check for now. Anyway, there needs to be at least one stabilizing branch (save point, so to 
speak) before we can go full steam with the trunk. And there's still no such branch yet.

Jonathon

David E. Jones wrote:
> 
> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
> 
>> We shouldn't turn away complex contributions anymore.
> 
> "We" do not now, nor have we ever, turned away a contribution because it 
> was complex.
> 
>> I myself have loads of enhancements (mostly to widget module) that I 
>> feel uneasy about releasing to the community, simply because of this 
>> odd use of trunk: it's used like a slow-moving release branch that is 
>> unable to handle introductions of radical enhancements.
>>
>> Yet, this somewhat slow-moving trunk isn't still enough and focused 
>> enough on achieving release-quality stability. It's the worst of both 
>> worlds: it's not rapid enough to allow for radical progress, and not 
>> calm and focused-on-cleaning-up enough to produce a stable release for 
>> non-OFBiz developers.
> 
> Could you do us all a big favor Jonathon? Your comments seem to be 
> fairly consistent along these lines. I think what would be helpful to 
> you, and to anyone reading and agreeing with your comments, is to step 
> back and try to explain why things are the way they are. Feel free to 
> share that with the group for a sanity check if you'd like.
> 
> -David
> 
> 

Re: Ofbiz Contribution Proposal

["David E. Jones" <jo...@hotwaxmedia.com>]

On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:

> We shouldn't turn away complex contributions anymore.

"We" do not now, nor have we ever, turned away a contribution because  
it was complex.

> I myself have loads of enhancements (mostly to widget module) that  
> I feel uneasy about releasing to the community, simply because of  
> this odd use of trunk: it's used like a slow-moving release branch  
> that is unable to handle introductions of radical enhancements.
>
> Yet, this somewhat slow-moving trunk isn't still enough and focused  
> enough on achieving release-quality stability. It's the worst of  
> both worlds: it's not rapid enough to allow for radical progress,  
> and not calm and focused-on-cleaning-up enough to produce a stable  
> release for non-OFBiz developers.

Could you do us all a big favor Jonathon? Your comments seem to be  
fairly consistent along these lines. I think what would be helpful to  
you, and to anyone reading and agreeing with your comments, is to  
step back and try to explain why things are the way they are. Feel  
free to share that with the group for a sanity check if you'd like.

-David

Re: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Karl,

I believe the community is branching a release this Friday (now?).

After forking a release branch, the trunk can and SHOULD be free to blaze ahead rapidly, even with 
loads of new enhancements from yourself.

The idea of separate branches is simply to have multiple prongs of activity for various 
intentions, each prong insulated from the others. The release branch will be "slow-moving waters", 
gradually and surely stabilizing into a solid-in-stone release. The trunk is NOT meant for 
stabilizing, but for ongoing progress.

In the worst case, the community should consider forking an "exploratory" branch to test out your 
contributions, and then merge those contributions into trunk after ironing out any 
incompatibilities between OFBiz codes and your codes.

I believe you are already maintaining your own SVN for your own modified OFBiz, and you should be 
pulling in updates regularly from OFBiz trunk. I am doing just that.

If this is your objective:

To get the latest and greatest of OFBiz merged with your proven (2 years) enhancements,

let me know. I'll take in your enhancements and merge them in with OFBiz trunk right now, and then 
hand the whole "greater than sum of parts" assembly back to you. We'll iron out incompatibilities 
rapidly in another "slow-moving waters" branch called "Karl's Exploratory Branch".

Only condition, of course, is that you expressly indicate that your enhancements are to be put 
under ASL, or any other license completely compatible with the one OFBiz is currently using.

We shouldn't turn away complex contributions anymore. I myself have loads of enhancements (mostly 
to widget module) that I feel uneasy about releasing to the community, simply because of this odd 
use of trunk: it's used like a slow-moving release branch that is unable to handle introductions 
of radical enhancements.

Yet, this somewhat slow-moving trunk isn't still enough and focused enough on achieving 
release-quality stability. It's the worst of both worlds: it's not rapid enough to allow for 
radical progress, and not calm and focused-on-cleaning-up enough to produce a stable release for 
non-OFBiz developers.

Jonathon

Anil Patel wrote:
> Thanks for your. Contribution, they are always welcome. Contributions
> of this size may take long to before they get into trunk, in this case
> timing if also a factor. Community is planning a release after long
> time so they will try to avoid major changes to framework component.
> 
> Please be patient I am sure some body will look at it.
> 
> In order to make it easy to review ca it be broken into smaller patches.
> 
> Regards
> 
> 
> On 4/20/07, Eilebrecht, Karl  (Key-Work) <ka...@key-work.de> 
> wrote:
>> Hi,
>>
>>
>>
>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>
>>
>>
>> Last year I had mail contact with David.
>>
>>
>>
>> He recommended to contribute changes to the Ofbiz Community regularly
>> whenever possible and useful.
>>
>>
>>
>> It is a long time since this happened, but we finally convinced our
>> management to try
>>
>>
>>
>> to contribute some changes and extensions to the Ofbiz community.
>>
>>
>>
>> I read the FAQ and found out that especially complex changes might take a
>> long time
>>
>>
>>
>> and we may need some "community attendance".
>>
>>
>>
>> David told me to place our proposal at the Ofbiz-WIKI
>>
>> and to send a link to this mailing list.
>>
>>
>>
>> This is our "trial balloon" to find out whether our changes and 
>> improvements
>>
>>
>>
>> are welcome and how we could integrate them during the next months.
>>
>>
>>
>> I.e. the following extensions may also be interesting for other members
>>
>> of the community:
>>
>>
>>
>>  * Advanced custom SQL integration
>>
>>  * advanced sorting (locale, collation, natural sort)
>>
>>  * completely refactored TransactionUtil with documentation and hints
>>
>>  * on-demand "real"-sql-logging for ALL ofbiz statements
>>
>> ...
>>
>>
>>
>> I placed our stuff at
>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>
>> and hope one of the "Ofbiz gurus" will have a look at the attached 
>> stuff to
>> make a statement.
>>
>>
>>
>> Thank you in advance!
>>
>>
>>
>> Best regards
>>
>>
>>
>> Karl Eilebrecht
>>
>> -- 
>> Karl Eilebrecht
>> Key-Work Consulting GmbH
>>
>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>> karl.eilebrecht@key-work.de
>>
>>
>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>
>>
> 
> 

Re: Ofbiz Contribution Proposal

[Anil Patel <to...@gmail.com>]

Thanks for your. Contribution, they are always welcome. Contributions
of this size may take long to before they get into trunk, in this case
timing if also a factor. Community is planning a release after long
time so they will try to avoid major changes to framework component.

Please be patient I am sure some body will look at it.

In order to make it easy to review ca it be broken into smaller patches.

Regards


On 4/20/07, Eilebrecht, Karl  (Key-Work) <ka...@key-work.de> wrote:
> Hi,
>
>
>
> we use Ofbiz (mostly the entity engine) for over 2 years now.
>
>
>
> Last year I had mail contact with David.
>
>
>
> He recommended to contribute changes to the Ofbiz Community regularly
> whenever possible and useful.
>
>
>
> It is a long time since this happened, but we finally convinced our
> management to try
>
>
>
> to contribute some changes and extensions to the Ofbiz community.
>
>
>
> I read the FAQ and found out that especially complex changes might take a
> long time
>
>
>
> and we may need some "community attendance".
>
>
>
> David told me to place our proposal at the Ofbiz-WIKI
>
> and to send a link to this mailing list.
>
>
>
> This is our "trial balloon" to find out whether our changes and improvements
>
>
>
> are welcome and how we could integrate them during the next months.
>
>
>
> I.e. the following extensions may also be interesting for other members
>
> of the community:
>
>
>
>  * Advanced custom SQL integration
>
>  * advanced sorting (locale, collation, natural sort)
>
>  * completely refactored TransactionUtil with documentation and hints
>
>  * on-demand "real"-sql-logging for ALL ofbiz statements
>
> ...
>
>
>
> I placed our stuff at
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>
> and hope one of the "Ofbiz gurus" will have a look at the attached stuff to
> make a statement.
>
>
>
> Thank you in advance!
>
>
>
> Best regards
>
>
>
> Karl Eilebrecht
>
> --
> Karl Eilebrecht
> Key-Work Consulting GmbH
>
> Kriegsstr. 100 - 76133 Karlsruhe - Germany
> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
> karl.eilebrecht@key-work.de
>
>
> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> Geschäftsführer: Andreas Stappert, Tobin Wotring
>
>

Re: Ofbiz Contribution Proposal

[Jacques Le Roux <ja...@les7arts.com>]

Karl,

BTW I just had a very quick look at your pdf documentation, sounds very
interesting !

Thanks to share !

Jacques

> Karl,
>
> I would recommend considering to use OFBiz Jira because of licence
> reasons ("joint works" are not eligible to be commited). Jonathon is
> able to explain that deeper to you if needed. You may also find
> discussions about this topic in Nabble (using "joint works" research).
>
> Thanks
>
> Jacques
>
> De : "Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>
>
> > Hi Jonathan, hi Chris,
> >
> > thank you for your feedback (and also thank you for stiring up a
> hornet's nest ;-) )
> >
> > @Chris: I will try to answer your questions on the wiki page:
> >
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> > I think this is more comfortable to retrace.
> >
> > @Jonathan: It's a great offer you made to take a look on our code
and
> to
> > evtl. merge it! What's the best way to provide the code to you?
> > I'll have to prepare some things before:
> > - for historical reasons we have a CVS repository and I
> > or one of my colleagues will set up an SVN client. Is it more
> convenient to
> > you to get an archive for the first review or would you recommend to
> > pump the sources into a repository? (where?)
> > - I already have added the Apache-Header (ASL) to all of the classes
> > we might contribute.
> > - I'll have to replace all tabs in the sources by 4 spaces.
> >
> > The rest I think should be not too complex, our last framework merge
> (with trunk) was on 2007-01-05, I don't think there are dramatic low
> level interface changes since then.
> >
> > We have already switched to Java 6 but all the classes to be
> contributed
> > are compileable with Java 1.4.
> >
> > Regards.
> > Karl
> >
> > BTW: During the next weeks there may be some "communication delays"
> because I'll not be in the office all the time. So please don't worry
if
> an email answer needs some days, thanks!
> >
> >
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Chris Howe [mailto:cjhowe76013@yahoo.com]
> > Gesendet: Samstag, 21. April 2007 08:33
> > An: dev@ofbiz.apache.org
> > Betreff: Re: Ofbiz Contribution Proposal
> >
> > Hi Karl,
> >
> > I had the opportunity today to quickly read over your introductions.
> > And must say it looks very interesting.  Unfortunately, for my being
> > able to add input to the process, the improvements are in areas as
an
> > OFBiz user, that I take for granted and don't really get my hands
> dirty
> > with.
> >
> > I'll need to read over the transaction part again to ask any
> > intelligent questions, so I'll leave that for later.
> >
> > The custom SQL stuff looked very interesting and probably one of the
> > larger areas of benefit as more and more people are getting to the
> > point of locating bottlenecks in their applications.  I was
wondering
> > if there might be some benefit in encapsulating the stored sql
> > statements it in an XML structure to be able to better take
advantage
> > of some META data/commenting that you discussed as well as potential
> of
> > some reusability and structuring of those custom statements.
> >
> > Perhaps, I need to reread the logging discussion again, and ask if
> this
> > is largely supported among other databases, but can't most of these
> > logging of the sql statements be handled in the database's log, if
> > configured to do so?  I recall a mention that the developer may not
> > have sufficient access to the database server to ascertain the
> database
> > logs...is this case where the logging proposal would be more
> > beneficial?
> >
> > Thank you and Key-Work very much for bringing these enhancements
back
> > to the community!
> >
> > Chris
> >
> > --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>
> wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > we use Ofbiz (mostly the entity engine) for over 2 years now.
> > >
> > >
> > >
> > > Last year I had mail contact with David.
> > >
> > >
> > >
> > > He recommended to contribute changes to the Ofbiz Community
> regularly
> > > whenever possible and useful.
> > >
> > >
> > >
> > > It is a long time since this happened, but we finally convinced
our
> > > management to try
> > >
> > >
> > >
> > > to contribute some changes and extensions to the Ofbiz community.
> > >
> > >
> > >
> > > I read the FAQ and found out that especially complex changes might
> > > take a long time
> > >
> > >
> > >
> > > and we may need some "community attendance".
> > >
> > >
> > >
> > > David told me to place our proposal at the Ofbiz-WIKI
> > >
> > > and to send a link to this mailing list.
> > >
> > >
> > >
> > > This is our "trial balloon" to find out whether our changes and
> > > improvements
> > >
> > >
> > >
> > > are welcome and how we could integrate them during the next
months.
> > >
> > >
> > >
> > > I.e. the following extensions may also be interesting for other
> > > members
> > >
> > > of the community:
> > >
> > >
> > >
> > >  * Advanced custom SQL integration
> > >
> > >  * advanced sorting (locale, collation, natural sort)
> > >
> > >  * completely refactored TransactionUtil with documentation and
> hints
> > >
> > >
> > >  * on-demand "real"-sql-logging for ALL ofbiz statements
> > >
> > > ...
> > >
> > >
> > >
> > > I placed our stuff at
> > >
> >
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> > >
> > > and hope one of the "Ofbiz gurus" will have a look at the attached
> > > stuff to make a statement.
> > >
> > >
> > >
> > > Thank you in advance!
> > >
> > >
> > >
> > > Best regards
> > >
> > >
> > >
> > > Karl Eilebrecht
> > >
> > > -- 
> > > Karl Eilebrecht
> > > Key-Work Consulting GmbH
> > >
> > > Kriegsstr. 100 - 76133 Karlsruhe - Germany
> > > Fon: +49-721-78203-277 - Fax: +49-721-78203-10
> > > karl.eilebrecht@key-work.de
> > >
> > >
> > > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> > > Geschäftsführer: Andreas Stappert, Tobin Wotring
> > >
> > >
> >

Re: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Jacques,

How about a Jira issue entitled "Merge of Karl's enhancements"? It'll be difficult for Karl to 
break up his enhancements into individual elements, unless he doesn't mind taking the time to do so.

Read my other post to Karl for what I proposed. All fixes I do for Karl, if they are even 
necessary, will be done under Karl's license. Then it'll be up to Karl to contribute those fixes 
under ASL. Does that make sense? My proposal will not require disturbing the OFBiz SVN.

Jonathon

Jacques Le Roux wrote:
> Karl,
> 
> I would recommend considering to use OFBiz Jira because of licence
> reasons ("joint works" are not eligible to be commited). Jonathon is
> able to explain that deeper to you if needed. You may also find
> discussions about this topic in Nabble (using "joint works" research).
> 
> Thanks
> 
> Jacques
> 
> De : "Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>
> 
>> Hi Jonathan, hi Chris,
>>
>> thank you for your feedback (and also thank you for stiring up a
> hornet's nest ;-) )
>> @Chris: I will try to answer your questions on the wiki page:
>>
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>> I think this is more comfortable to retrace.
>>
>> @Jonathan: It's a great offer you made to take a look on our code and
> to
>> evtl. merge it! What's the best way to provide the code to you?
>> I'll have to prepare some things before:
>> - for historical reasons we have a CVS repository and I
>> or one of my colleagues will set up an SVN client. Is it more
> convenient to
>> you to get an archive for the first review or would you recommend to
>> pump the sources into a repository? (where?)
>> - I already have added the Apache-Header (ASL) to all of the classes
>> we might contribute.
>> - I'll have to replace all tabs in the sources by 4 spaces.
>>
>> The rest I think should be not too complex, our last framework merge
> (with trunk) was on 2007-01-05, I don't think there are dramatic low
> level interface changes since then.
>> We have already switched to Java 6 but all the classes to be
> contributed
>> are compileable with Java 1.4.
>>
>> Regards.
>> Karl
>>
>> BTW: During the next weeks there may be some "communication delays"
> because I'll not be in the office all the time. So please don't worry if
> an email answer needs some days, thanks!
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com]
>> Gesendet: Samstag, 21. April 2007 08:33
>> An: dev@ofbiz.apache.org
>> Betreff: Re: Ofbiz Contribution Proposal
>>
>> Hi Karl,
>>
>> I had the opportunity today to quickly read over your introductions.
>> And must say it looks very interesting.  Unfortunately, for my being
>> able to add input to the process, the improvements are in areas as an
>> OFBiz user, that I take for granted and don't really get my hands
> dirty
>> with.
>>
>> I'll need to read over the transaction part again to ask any
>> intelligent questions, so I'll leave that for later.
>>
>> The custom SQL stuff looked very interesting and probably one of the
>> larger areas of benefit as more and more people are getting to the
>> point of locating bottlenecks in their applications.  I was wondering
>> if there might be some benefit in encapsulating the stored sql
>> statements it in an XML structure to be able to better take advantage
>> of some META data/commenting that you discussed as well as potential
> of
>> some reusability and structuring of those custom statements.
>>
>> Perhaps, I need to reread the logging discussion again, and ask if
> this
>> is largely supported among other databases, but can't most of these
>> logging of the sql statements be handled in the database's log, if
>> configured to do so?  I recall a mention that the developer may not
>> have sufficient access to the database server to ascertain the
> database
>> logs...is this case where the logging proposal would be more
>> beneficial?
>>
>> Thank you and Key-Work very much for bringing these enhancements back
>> to the community!
>>
>> Chris
>>
>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>
> wrote:
>>> Hi,
>>>
>>>
>>>
>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>
>>>
>>>
>>> Last year I had mail contact with David.
>>>
>>>
>>>
>>> He recommended to contribute changes to the Ofbiz Community
> regularly
>>> whenever possible and useful.
>>>
>>>
>>>
>>> It is a long time since this happened, but we finally convinced our
>>> management to try
>>>
>>>
>>>
>>> to contribute some changes and extensions to the Ofbiz community.
>>>
>>>
>>>
>>> I read the FAQ and found out that especially complex changes might
>>> take a long time
>>>
>>>
>>>
>>> and we may need some "community attendance".
>>>
>>>
>>>
>>> David told me to place our proposal at the Ofbiz-WIKI
>>>
>>> and to send a link to this mailing list.
>>>
>>>
>>>
>>> This is our "trial balloon" to find out whether our changes and
>>> improvements
>>>
>>>
>>>
>>> are welcome and how we could integrate them during the next months.
>>>
>>>
>>>
>>> I.e. the following extensions may also be interesting for other
>>> members
>>>
>>> of the community:
>>>
>>>
>>>
>>>  * Advanced custom SQL integration
>>>
>>>  * advanced sorting (locale, collation, natural sort)
>>>
>>>  * completely refactored TransactionUtil with documentation and
> hints
>>>
>>>  * on-demand "real"-sql-logging for ALL ofbiz statements
>>>
>>> ...
>>>
>>>
>>>
>>> I placed our stuff at
>>>
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>> and hope one of the "Ofbiz gurus" will have a look at the attached
>>> stuff to make a statement.
>>>
>>>
>>>
>>> Thank you in advance!
>>>
>>>
>>>
>>> Best regards
>>>
>>>
>>>
>>> Karl Eilebrecht
>>>
>>> -- 
>>> Karl Eilebrecht
>>> Key-Work Consulting GmbH
>>>
>>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>>> karl.eilebrecht@key-work.de
>>>
>>>
>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>
>>>
> 
> 

Re: Ofbiz Contribution Proposal

[Jacques Le Roux <ja...@les7arts.com>]

Karl,

I would recommend considering to use OFBiz Jira because of licence
reasons ("joint works" are not eligible to be commited). Jonathon is
able to explain that deeper to you if needed. You may also find
discussions about this topic in Nabble (using "joint works" research).

Thanks

Jacques

De : "Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>

> Hi Jonathan, hi Chris,
>
> thank you for your feedback (and also thank you for stiring up a
hornet's nest ;-) )
>
> @Chris: I will try to answer your questions on the wiki page:
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> I think this is more comfortable to retrace.
>
> @Jonathan: It's a great offer you made to take a look on our code and
to
> evtl. merge it! What's the best way to provide the code to you?
> I'll have to prepare some things before:
> - for historical reasons we have a CVS repository and I
> or one of my colleagues will set up an SVN client. Is it more
convenient to
> you to get an archive for the first review or would you recommend to
> pump the sources into a repository? (where?)
> - I already have added the Apache-Header (ASL) to all of the classes
> we might contribute.
> - I'll have to replace all tabs in the sources by 4 spaces.
>
> The rest I think should be not too complex, our last framework merge
(with trunk) was on 2007-01-05, I don't think there are dramatic low
level interface changes since then.
>
> We have already switched to Java 6 but all the classes to be
contributed
> are compileable with Java 1.4.
>
> Regards.
> Karl
>
> BTW: During the next weeks there may be some "communication delays"
because I'll not be in the office all the time. So please don't worry if
an email answer needs some days, thanks!
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Chris Howe [mailto:cjhowe76013@yahoo.com]
> Gesendet: Samstag, 21. April 2007 08:33
> An: dev@ofbiz.apache.org
> Betreff: Re: Ofbiz Contribution Proposal
>
> Hi Karl,
>
> I had the opportunity today to quickly read over your introductions.
> And must say it looks very interesting.  Unfortunately, for my being
> able to add input to the process, the improvements are in areas as an
> OFBiz user, that I take for granted and don't really get my hands
dirty
> with.
>
> I'll need to read over the transaction part again to ask any
> intelligent questions, so I'll leave that for later.
>
> The custom SQL stuff looked very interesting and probably one of the
> larger areas of benefit as more and more people are getting to the
> point of locating bottlenecks in their applications.  I was wondering
> if there might be some benefit in encapsulating the stored sql
> statements it in an XML structure to be able to better take advantage
> of some META data/commenting that you discussed as well as potential
of
> some reusability and structuring of those custom statements.
>
> Perhaps, I need to reread the logging discussion again, and ask if
this
> is largely supported among other databases, but can't most of these
> logging of the sql statements be handled in the database's log, if
> configured to do so?  I recall a mention that the developer may not
> have sufficient access to the database server to ascertain the
database
> logs...is this case where the logging proposal would be more
> beneficial?
>
> Thank you and Key-Work very much for bringing these enhancements back
> to the community!
>
> Chris
>
> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>
wrote:
>
> > Hi,
> >
> >
> >
> > we use Ofbiz (mostly the entity engine) for over 2 years now.
> >
> >
> >
> > Last year I had mail contact with David.
> >
> >
> >
> > He recommended to contribute changes to the Ofbiz Community
regularly
> > whenever possible and useful.
> >
> >
> >
> > It is a long time since this happened, but we finally convinced our
> > management to try
> >
> >
> >
> > to contribute some changes and extensions to the Ofbiz community.
> >
> >
> >
> > I read the FAQ and found out that especially complex changes might
> > take a long time
> >
> >
> >
> > and we may need some "community attendance".
> >
> >
> >
> > David told me to place our proposal at the Ofbiz-WIKI
> >
> > and to send a link to this mailing list.
> >
> >
> >
> > This is our "trial balloon" to find out whether our changes and
> > improvements
> >
> >
> >
> > are welcome and how we could integrate them during the next months.
> >
> >
> >
> > I.e. the following extensions may also be interesting for other
> > members
> >
> > of the community:
> >
> >
> >
> >  * Advanced custom SQL integration
> >
> >  * advanced sorting (locale, collation, natural sort)
> >
> >  * completely refactored TransactionUtil with documentation and
hints
> >
> >
> >  * on-demand "real"-sql-logging for ALL ofbiz statements
> >
> > ...
> >
> >
> >
> > I placed our stuff at
> >
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> >
> > and hope one of the "Ofbiz gurus" will have a look at the attached
> > stuff to make a statement.
> >
> >
> >
> > Thank you in advance!
> >
> >
> >
> > Best regards
> >
> >
> >
> > Karl Eilebrecht
> >
> > -- 
> > Karl Eilebrecht
> > Key-Work Consulting GmbH
> >
> > Kriegsstr. 100 - 76133 Karlsruhe - Germany
> > Fon: +49-721-78203-277 - Fax: +49-721-78203-10
> > karl.eilebrecht@key-work.de
> >
> >
> > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> > Geschäftsführer: Andreas Stappert, Tobin Wotring
> >
> >
>

Re: AW: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Karl,

The URL David has pointed to does contain best practices for collaborative work. And yes, that 
document, if followed strictly, does give your contributions a very high chance of getting into 
OFBiz SVN. It is also my preferred way of doing collaborative work --- structured and controlled.

I'm sorry that you will, according to the document, need to do a lot of work before your 
contribution is considered "easy enough to review". A few issues require substantial manpower, for 
eg one that is major in effort though trivial in code incompatibility is: "do your best to avoid 
to mix formatting changes with relevant changes". Even for me to review your work, it'll be much 
faster and easier if you can remove formatting changes and change tabs to spaces, etc.

Also, there's a way to do "additive" code changes with _minimal_footprint_, so you get 
backward-compatibility plus you can produce neat small patches to community. If this isn't your 
coding style, it'll also be more difficult for me review your work.

According to the document, the first rule for contributing large blocks of code is: don't.

A possible difference between the way I do reviews and the way the community does it could be: 
"especially if [the code change] touches ANY lower level or more sensitive or complex artifacts, 
and this requires more thorough review". Rather than discuss whether your change affects usages of 
say method SomeClass.someMethod(), I perform a simple reverse-engineering process to find out for 
certain. Of course, how well I catch affected usages depends entirely on this reverse-engineering 
process! So far, I dare say OFBiz is structured enough to allow a 100% catch with my methods; the 
possible few that slip through could've been coded in very non-standard ways that should be 
changed anyway. A side-effect of this process: highlight non-standard ways of invoking certain 
functions, and change them ONLY if they're wrong (or fine-tune my catch process).

That's the best explanation I can muster, I'm afraid. I hope that makes sense to you.

Remember the 4-step process? We can stop at step 2, getting the latest of OFBiz to play well with 
your work, for now. Then decide what to do later on.

As I had guessed, there could be many large block contributions out there, and authors who can't 
be bothered to spend the time to feed them back to OFBiz. I don't have a solution to this.

Jacques and David (according to document) are correct in saying that the legal review process is 
difficult for large block contributions. So, you could be looking at keeping your codes in step 
with OFBiz SVN, rather than merging your codes into OFBiz SVN. You don't have to worry if you 
don't absolutely need to share your work; you only should worry if you don't know your work well 
(coded by others) and you want it tested and debugged by the public over time.

Always do try to follow the document for collaborative work, inhouse or with OFBiz or in any projects.

Lastly, I'd like to point out to all SVN users point 3.1 in the document: "first do no harm. 
Nothing should be committed that breaks existing functionality". That applies mainly to the trunk. 
Anyway, OFBiz only has one branch --- trunk. I've explained before how SVN lets you do bold moves 
in insulated branches. Remember that "insulated branches" can also be your own private repositories.

Jonathon

David E. Jones wrote:
> 
> Karl,
> 
> For best results I HIGHLY recommend reading and following the 
> recommendations in the Contributors Best Practices document here:
> 
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> 
> A lot of people have ideas about how to do different things, but this is 
> the document prepared and maintained by the OFBiz PMC and committers and 
> following the recommendations there will give your contributions the 
> best chance of getting in, and probably be the easiest way to go for 
> both you and the committers who review and commit your contribution.
> 
> Thanks for your patience, and sorry for the total chaos this thread has 
> become. It is an unfortunate side effect of not taking a heavy-handed 
> and centralized approach to creating and maintaining software.
> 
> -David
> 
> 
> On Apr 23, 2007, at 6:33 AM, Eilebrecht, Karl ((Key-Work)) wrote:
> 
>> Jonathon,
>>
>> I'll discuss this with a colleague.
>> As I understand first option is to send you
>> two archives, one with the original distribution we
>> downloaded in January and a second one also including
>> our changes.
>> Second option is to download the next release (coming these days?),
>> merge this and send you the pre-merged archive to do a check.
>>
>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>> Is it correct that I will have to attach a large archive to an issue
>> created in advance by yourself or myself?
>>
>> If you're going to create the initial issue (mentioned in your last 
>> posting)
>> please send me the issue number. I'll also put a link on that wiki page.
>>
>> Thanks for your support!
>>
>> Regards.
>> Karl
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jonathon -- Improov [mailto:jonw@improov.com]
>> Gesendet: Montag, 23. April 2007 13:38
>> An: dev@ofbiz.apache.org
>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>
>> Karl,
>>
>> It's a great offer on your part too, to let us have those codes!
>>
>> If you've done a merge with OFBiz trunk on 2007-01-05, that means you 
>> already know how to keep in
>> step with OFBiz trunk head! You can actually do what I do, on your own.
>>
>> That said, if you still need my help, see the following.
>>
>> These are what I'll need from you:
>>
>> a. Exact OFBiz revision you started off from.
>>
>>     (Try to send me a tarball of that revision so I don't have to do a 
>> SVN
>>     download which can be a real pain thanks to the 35MB of 3rd-party
>>     libraries. My own SVN doesn't include those 35MB or 3rd-party 
>> binaries; let
>>     me know if you want advise on how to cut a lean SVN without 
>> binaries.)
>>
>> b. Tarball of your latest work you want merged with OFBiz trunk head.
>>
>> (Please do an "export"; I don't need the .cvs files.)
>>
>> What I will give you is a tarball of this: OFBiz trunk head (I'll 
>> state revision for our
>> reference) married with the latest of your work.
>>
>> You will have to test this tarball over time, get back to me about 
>> problems, and I'll keep sending
>> you fixed tarballs (or deltas, rather). We won't even have to touch 
>> the official OFBiz SVN.
>>
>> For the initial "review", I will at least make sure it compiles and 
>> runs. You will have to test
>> your own functions to see they still work with the latest updates from 
>> OFBiz SVN.
>>
>> So, here's the summary of the process:
>>
>> 1. We merge latest of OFBiz with your stuff.
>>
>> 2. Review A: We make sure your stuff still works.
>>
>> 3. Review B: We (or community) make sure the general OFBiz stuff still 
>> works.
>>
>> 4. We submit a patch (diff OFBiz to Your_work) to community.
>>
>> And then the ball will be in their (committers') court.
>>
>> Generally, you can pretty much stop at step 2 if all you want is the 
>> latest of OFBiz working with
>> your stuff. If you had done your customizations in a 
>> backward-compatible manner, step 3 won't be
>> very difficult or even necessary at all.
>>
>> Jonathon
>>
>> Eilebrecht, Karl (Key-Work) wrote:
>>> Hi Jonathan, hi Chris,
>>>
>>> thank you for your feedback (and also thank you for stiring up a 
>>> hornet's nest ;-) )
>>>
>>> @Chris: I will try to answer your questions on the wiki page:
>>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>> I think this is more comfortable to retrace.
>>>
>>> @Jonathan: It's a great offer you made to take a look on our code and to
>>> evtl. merge it! What's the best way to provide the code to you?
>>> I'll have to prepare some things before:
>>> - for historical reasons we have a CVS repository and I
>>> or one of my colleagues will set up an SVN client. Is it more 
>>> convenient to
>>> you to get an archive for the first review or would you recommend to
>>> pump the sources into a repository? (where?)
>>> - I already have added the Apache-Header (ASL) to all of the classes
>>> we might contribute.
>>> - I'll have to replace all tabs in the sources by 4 spaces.
>>>
>>> The rest I think should be not too complex, our last framework merge 
>>> (with trunk) was on 2007-01-05, I don't think there are dramatic low 
>>> level interface changes since then.
>>>
>>> We have already switched to Java 6 but all the classes to be contributed
>>> are compileable with Java 1.4.
>>>
>>> Regards.
>>> Karl
>>>
>>> BTW: During the next weeks there may be some "communication delays" 
>>> because I'll not be in the office all the time. So please don't worry 
>>> if an email answer needs some days, thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com]
>>> Gesendet: Samstag, 21. April 2007 08:33
>>> An: dev@ofbiz.apache.org
>>> Betreff: Re: Ofbiz Contribution Proposal
>>>
>>> Hi Karl,
>>>
>>> I had the opportunity today to quickly read over your introductions.
>>> And must say it looks very interesting.  Unfortunately, for my being
>>> able to add input to the process, the improvements are in areas as an
>>> OFBiz user, that I take for granted and don't really get my hands dirty
>>> with.
>>>
>>> I'll need to read over the transaction part again to ask any
>>> intelligent questions, so I'll leave that for later.
>>>
>>> The custom SQL stuff looked very interesting and probably one of the
>>> larger areas of benefit as more and more people are getting to the
>>> point of locating bottlenecks in their applications.  I was wondering
>>> if there might be some benefit in encapsulating the stored sql
>>> statements it in an XML structure to be able to better take advantage
>>> of some META data/commenting that you discussed as well as potential of
>>> some reusability and structuring of those custom statements.
>>>
>>> Perhaps, I need to reread the logging discussion again, and ask if this
>>> is largely supported among other databases, but can't most of these
>>> logging of the sql statements be handled in the database's log, if
>>> configured to do so?  I recall a mention that the developer may not
>>> have sufficient access to the database server to ascertain the database
>>> logs...is this case where the logging proposal would be more
>>> beneficial?
>>>
>>> Thank you and Key-Work very much for bringing these enhancements back
>>> to the community!
>>>
>>> Chris
>>>
>>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>>
>>>>
>>>>
>>>> Last year I had mail contact with David.
>>>>
>>>>
>>>>
>>>> He recommended to contribute changes to the Ofbiz Community regularly
>>>> whenever possible and useful.
>>>>
>>>>
>>>>
>>>> It is a long time since this happened, but we finally convinced our
>>>> management to try
>>>>
>>>>
>>>>
>>>> to contribute some changes and extensions to the Ofbiz community.
>>>>
>>>>
>>>>
>>>> I read the FAQ and found out that especially complex changes might
>>>> take a long time
>>>>
>>>>
>>>>
>>>> and we may need some "community attendance".
>>>>
>>>>
>>>>
>>>> David told me to place our proposal at the Ofbiz-WIKI
>>>>
>>>> and to send a link to this mailing list.
>>>>
>>>>
>>>>
>>>> This is our "trial balloon" to find out whether our changes and
>>>> improvements
>>>>
>>>>
>>>>
>>>> are welcome and how we could integrate them during the next months.
>>>>
>>>>
>>>>
>>>> I.e. the following extensions may also be interesting for other
>>>> members
>>>>
>>>> of the community:
>>>>
>>>>
>>>>
>>>>  * Advanced custom SQL integration
>>>>
>>>>  * advanced sorting (locale, collation, natural sort)
>>>>
>>>>  * completely refactored TransactionUtil with documentation and hints
>>>>
>>>>
>>>>  * on-demand "real"-sql-logging for ALL ofbiz statements
>>>>
>>>> ...
>>>>
>>>>
>>>>
>>>> I placed our stuff at
>>>>
>>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>>> and hope one of the "Ofbiz gurus" will have a look at the attached
>>>> stuff to make a statement.
>>>>
>>>>
>>>>
>>>> Thank you in advance!
>>>>
>>>>
>>>>
>>>> Best regards
>>>>
>>>>
>>>>
>>>> Karl Eilebrecht
>>>>
>>>> --Karl Eilebrecht
>>>> Key-Work Consulting GmbH
>>>>
>>>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>>>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>>>> karl.eilebrecht@key-work.de
>>>>
>>>>
>>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>>
>>>>
>>>
>>>
>>>
>>
> 

Re: AW: Ofbiz Contribution Proposal

["David E. Jones" <jo...@hotwaxmedia.com>]

Karl,

For best results I HIGHLY recommend reading and following the  
recommendations in the Contributors Best Practices document here:

http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices

A lot of people have ideas about how to do different things, but this  
is the document prepared and maintained by the OFBiz PMC and  
committers and following the recommendations there will give your  
contributions the best chance of getting in, and probably be the  
easiest way to go for both you and the committers who review and  
commit your contribution.

Thanks for your patience, and sorry for the total chaos this thread  
has become. It is an unfortunate side effect of not taking a heavy- 
handed and centralized approach to creating and maintaining software.

-David


On Apr 23, 2007, at 6:33 AM, Eilebrecht, Karl ((Key-Work)) wrote:

> Jonathon,
>
> I'll discuss this with a colleague.
> As I understand first option is to send you
> two archives, one with the original distribution we
> downloaded in January and a second one also including
> our changes.
> Second option is to download the next release (coming these days?),
> merge this and send you the pre-merged archive to do a check.
>
> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
> Is it correct that I will have to attach a large archive to an issue
> created in advance by yourself or myself?
>
> If you're going to create the initial issue (mentioned in your last  
> posting)
> please send me the issue number. I'll also put a link on that wiki  
> page.
>
> Thanks for your support!
>
> Regards.
> Karl
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Jonathon -- Improov [mailto:jonw@improov.com]
> Gesendet: Montag, 23. April 2007 13:38
> An: dev@ofbiz.apache.org
> Betreff: Re: AW: Ofbiz Contribution Proposal
>
> Karl,
>
> It's a great offer on your part too, to let us have those codes!
>
> If you've done a merge with OFBiz trunk on 2007-01-05, that means  
> you already know how to keep in
> step with OFBiz trunk head! You can actually do what I do, on your  
> own.
>
> That said, if you still need my help, see the following.
>
> These are what I'll need from you:
>
> a. Exact OFBiz revision you started off from.
>
>     (Try to send me a tarball of that revision so I don't have to  
> do a SVN
>     download which can be a real pain thanks to the 35MB of 3rd-party
>     libraries. My own SVN doesn't include those 35MB or 3rd-party  
> binaries; let
>     me know if you want advise on how to cut a lean SVN without  
> binaries.)
>
> b. Tarball of your latest work you want merged with OFBiz trunk head.
>
> (Please do an "export"; I don't need the .cvs files.)
>
> What I will give you is a tarball of this: OFBiz trunk head (I'll  
> state revision for our
> reference) married with the latest of your work.
>
> You will have to test this tarball over time, get back to me about  
> problems, and I'll keep sending
> you fixed tarballs (or deltas, rather). We won't even have to touch  
> the official OFBiz SVN.
>
> For the initial "review", I will at least make sure it compiles and  
> runs. You will have to test
> your own functions to see they still work with the latest updates  
> from OFBiz SVN.
>
> So, here's the summary of the process:
>
> 1. We merge latest of OFBiz with your stuff.
>
> 2. Review A: We make sure your stuff still works.
>
> 3. Review B: We (or community) make sure the general OFBiz stuff  
> still works.
>
> 4. We submit a patch (diff OFBiz to Your_work) to community.
>
> And then the ball will be in their (committers') court.
>
> Generally, you can pretty much stop at step 2 if all you want is  
> the latest of OFBiz working with
> your stuff. If you had done your customizations in a backward- 
> compatible manner, step 3 won't be
> very difficult or even necessary at all.
>
> Jonathon
>
> Eilebrecht, Karl (Key-Work) wrote:
>> Hi Jonathan, hi Chris,
>>
>> thank you for your feedback (and also thank you for stiring up a  
>> hornet's nest ;-) )
>>
>> @Chris: I will try to answer your questions on the wiki page:
>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution 
>> +Proposal
>> I think this is more comfortable to retrace.
>>
>> @Jonathan: It's a great offer you made to take a look on our code  
>> and to
>> evtl. merge it! What's the best way to provide the code to you?
>> I'll have to prepare some things before:
>> - for historical reasons we have a CVS repository and I
>> or one of my colleagues will set up an SVN client. Is it more  
>> convenient to
>> you to get an archive for the first review or would you recommend to
>> pump the sources into a repository? (where?)
>> - I already have added the Apache-Header (ASL) to all of the classes
>> we might contribute.
>> - I'll have to replace all tabs in the sources by 4 spaces.
>>
>> The rest I think should be not too complex, our last framework  
>> merge (with trunk) was on 2007-01-05, I don't think there are  
>> dramatic low level interface changes since then.
>>
>> We have already switched to Java 6 but all the classes to be  
>> contributed
>> are compileable with Java 1.4.
>>
>> Regards.
>> Karl
>>
>> BTW: During the next weeks there may be some "communication  
>> delays" because I'll not be in the office all the time. So please  
>> don't worry if an email answer needs some days, thanks!
>>
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com]
>> Gesendet: Samstag, 21. April 2007 08:33
>> An: dev@ofbiz.apache.org
>> Betreff: Re: Ofbiz Contribution Proposal
>>
>> Hi Karl,
>>
>> I had the opportunity today to quickly read over your introductions.
>> And must say it looks very interesting.  Unfortunately, for my being
>> able to add input to the process, the improvements are in areas as an
>> OFBiz user, that I take for granted and don't really get my hands  
>> dirty
>> with.
>>
>> I'll need to read over the transaction part again to ask any
>> intelligent questions, so I'll leave that for later.
>>
>> The custom SQL stuff looked very interesting and probably one of the
>> larger areas of benefit as more and more people are getting to the
>> point of locating bottlenecks in their applications.  I was wondering
>> if there might be some benefit in encapsulating the stored sql
>> statements it in an XML structure to be able to better take advantage
>> of some META data/commenting that you discussed as well as  
>> potential of
>> some reusability and structuring of those custom statements.
>>
>> Perhaps, I need to reread the logging discussion again, and ask if  
>> this
>> is largely supported among other databases, but can't most of these
>> logging of the sql statements be handled in the database's log, if
>> configured to do so?  I recall a mention that the developer may not
>> have sufficient access to the database server to ascertain the  
>> database
>> logs...is this case where the logging proposal would be more
>> beneficial?
>>
>> Thank you and Key-Work very much for bringing these enhancements back
>> to the community!
>>
>> Chris
>>
>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>  
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>
>>>
>>>
>>> Last year I had mail contact with David.
>>>
>>>
>>>
>>> He recommended to contribute changes to the Ofbiz Community  
>>> regularly
>>> whenever possible and useful.
>>>
>>>
>>>
>>> It is a long time since this happened, but we finally convinced our
>>> management to try
>>>
>>>
>>>
>>> to contribute some changes and extensions to the Ofbiz community.
>>>
>>>
>>>
>>> I read the FAQ and found out that especially complex changes might
>>> take a long time
>>>
>>>
>>>
>>> and we may need some "community attendance".
>>>
>>>
>>>
>>> David told me to place our proposal at the Ofbiz-WIKI
>>>
>>> and to send a link to this mailing list.
>>>
>>>
>>>
>>> This is our "trial balloon" to find out whether our changes and
>>> improvements
>>>
>>>
>>>
>>> are welcome and how we could integrate them during the next months.
>>>
>>>
>>>
>>> I.e. the following extensions may also be interesting for other
>>> members
>>>
>>> of the community:
>>>
>>>
>>>
>>>  * Advanced custom SQL integration
>>>
>>>  * advanced sorting (locale, collation, natural sort)
>>>
>>>  * completely refactored TransactionUtil with documentation and  
>>> hints
>>>
>>>
>>>  * on-demand "real"-sql-logging for ALL ofbiz statements
>>>
>>> ...
>>>
>>>
>>>
>>> I placed our stuff at
>>>
>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution 
>> +Proposal
>>> and hope one of the "Ofbiz gurus" will have a look at the attached
>>> stuff to make a statement.
>>>
>>>
>>>
>>> Thank you in advance!
>>>
>>>
>>>
>>> Best regards
>>>
>>>
>>>
>>> Karl Eilebrecht
>>>
>>> -- 
>>> Karl Eilebrecht
>>> Key-Work Consulting GmbH
>>>
>>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>>> karl.eilebrecht@key-work.de
>>>
>>>
>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>
>>>
>>
>>
>>
>

Re: Ofbiz Contribution Proposal

[Jacques Le Roux <ja...@les7arts.com>]

Karl, Jonathon,

Please don't forget the "joint work" problem...

Jacques

De : "Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>
> Jonathon,
>
> I'll discuss this with a colleague.
> As I understand first option is to send you
> two archives, one with the original distribution we
> downloaded in January and a second one also including
> our changes.
> Second option is to download the next release (coming these days?),
> merge this and send you the pre-merged archive to do a check.
>
> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
> Is it correct that I will have to attach a large archive to an issue
> created in advance by yourself or myself?
>
> If you're going to create the initial issue (mentioned in your last
posting)
> please send me the issue number. I'll also put a link on that wiki
page.
>
> Thanks for your support!
>
> Regards.
> Karl
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Jonathon -- Improov [mailto:jonw@improov.com]
> Gesendet: Montag, 23. April 2007 13:38
> An: dev@ofbiz.apache.org
> Betreff: Re: AW: Ofbiz Contribution Proposal
>
> Karl,
>
> It's a great offer on your part too, to let us have those codes!
>
> If you've done a merge with OFBiz trunk on 2007-01-05, that means you
already know how to keep in
> step with OFBiz trunk head! You can actually do what I do, on your
own.
>
> That said, if you still need my help, see the following.
>
> These are what I'll need from you:
>
> a. Exact OFBiz revision you started off from.
>
>     (Try to send me a tarball of that revision so I don't have to do a
SVN
>     download which can be a real pain thanks to the 35MB of 3rd-party
>     libraries. My own SVN doesn't include those 35MB or 3rd-party
binaries; let
>     me know if you want advise on how to cut a lean SVN without
binaries.)
>
> b. Tarball of your latest work you want merged with OFBiz trunk head.
>
> (Please do an "export"; I don't need the .cvs files.)
>
> What I will give you is a tarball of this: OFBiz trunk head (I'll
state revision for our
> reference) married with the latest of your work.
>
> You will have to test this tarball over time, get back to me about
problems, and I'll keep sending
> you fixed tarballs (or deltas, rather). We won't even have to touch
the official OFBiz SVN.
>
> For the initial "review", I will at least make sure it compiles and
runs. You will have to test
> your own functions to see they still work with the latest updates from
OFBiz SVN.
>
> So, here's the summary of the process:
>
> 1. We merge latest of OFBiz with your stuff.
>
> 2. Review A: We make sure your stuff still works.
>
> 3. Review B: We (or community) make sure the general OFBiz stuff still
works.
>
> 4. We submit a patch (diff OFBiz to Your_work) to community.
>
> And then the ball will be in their (committers') court.
>
> Generally, you can pretty much stop at step 2 if all you want is the
latest of OFBiz working with
> your stuff. If you had done your customizations in a
backward-compatible manner, step 3 won't be
> very difficult or even necessary at all.
>
> Jonathon
>
> Eilebrecht, Karl (Key-Work) wrote:
> > Hi Jonathan, hi Chris,
> >
> > thank you for your feedback (and also thank you for stiring up a
hornet's nest ;-) )
> >
> > @Chris: I will try to answer your questions on the wiki page:
> >
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> > I think this is more comfortable to retrace.
> >
> > @Jonathan: It's a great offer you made to take a look on our code
and to
> > evtl. merge it! What's the best way to provide the code to you?
> > I'll have to prepare some things before:
> > - for historical reasons we have a CVS repository and I
> > or one of my colleagues will set up an SVN client. Is it more
convenient to
> > you to get an archive for the first review or would you recommend to
> > pump the sources into a repository? (where?)
> > - I already have added the Apache-Header (ASL) to all of the classes
> > we might contribute.
> > - I'll have to replace all tabs in the sources by 4 spaces.
> >
> > The rest I think should be not too complex, our last framework merge
(with trunk) was on 2007-01-05, I don't think there are dramatic low
level interface changes since then.
> >
> > We have already switched to Java 6 but all the classes to be
contributed
> > are compileable with Java 1.4.
> >
> > Regards.
> > Karl
> >
> > BTW: During the next weeks there may be some "communication delays"
because I'll not be in the office all the time. So please don't worry if
an email answer needs some days, thanks!
> >
> >
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Chris Howe [mailto:cjhowe76013@yahoo.com]
> > Gesendet: Samstag, 21. April 2007 08:33
> > An: dev@ofbiz.apache.org
> > Betreff: Re: Ofbiz Contribution Proposal
> >
> > Hi Karl,
> >
> > I had the opportunity today to quickly read over your introductions.
> > And must say it looks very interesting.  Unfortunately, for my being
> > able to add input to the process, the improvements are in areas as
an
> > OFBiz user, that I take for granted and don't really get my hands
dirty
> > with.
> >
> > I'll need to read over the transaction part again to ask any
> > intelligent questions, so I'll leave that for later.
> >
> > The custom SQL stuff looked very interesting and probably one of the
> > larger areas of benefit as more and more people are getting to the
> > point of locating bottlenecks in their applications.  I was
wondering
> > if there might be some benefit in encapsulating the stored sql
> > statements it in an XML structure to be able to better take
advantage
> > of some META data/commenting that you discussed as well as potential
of
> > some reusability and structuring of those custom statements.
> >
> > Perhaps, I need to reread the logging discussion again, and ask if
this
> > is largely supported among other databases, but can't most of these
> > logging of the sql statements be handled in the database's log, if
> > configured to do so?  I recall a mention that the developer may not
> > have sufficient access to the database server to ascertain the
database
> > logs...is this case where the logging proposal would be more
> > beneficial?
> >
> > Thank you and Key-Work very much for bringing these enhancements
back
> > to the community!
> >
> > Chris
> >
> > --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>
wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> we use Ofbiz (mostly the entity engine) for over 2 years now.
> >>
> >>
> >>
> >> Last year I had mail contact with David.
> >>
> >>
> >>
> >> He recommended to contribute changes to the Ofbiz Community
regularly
> >> whenever possible and useful.
> >>
> >>
> >>
> >> It is a long time since this happened, but we finally convinced our
> >> management to try
> >>
> >>
> >>
> >> to contribute some changes and extensions to the Ofbiz community.
> >>
> >>
> >>
> >> I read the FAQ and found out that especially complex changes might
> >> take a long time
> >>
> >>
> >>
> >> and we may need some "community attendance".
> >>
> >>
> >>
> >> David told me to place our proposal at the Ofbiz-WIKI
> >>
> >> and to send a link to this mailing list.
> >>
> >>
> >>
> >> This is our "trial balloon" to find out whether our changes and
> >> improvements
> >>
> >>
> >>
> >> are welcome and how we could integrate them during the next months.
> >>
> >>
> >>
> >> I.e. the following extensions may also be interesting for other
> >> members
> >>
> >> of the community:
> >>
> >>
> >>
> >>  * Advanced custom SQL integration
> >>
> >>  * advanced sorting (locale, collation, natural sort)
> >>
> >>  * completely refactored TransactionUtil with documentation and
hints
> >>
> >>
> >>  * on-demand "real"-sql-logging for ALL ofbiz statements
> >>
> >> ...
> >>
> >>
> >>
> >> I placed our stuff at
> >>
> >
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> >> and hope one of the "Ofbiz gurus" will have a look at the attached
> >> stuff to make a statement.
> >>
> >>
> >>
> >> Thank you in advance!
> >>
> >>
> >>
> >> Best regards
> >>
> >>
> >>
> >> Karl Eilebrecht
> >>
> >> -- 
> >> Karl Eilebrecht
> >> Key-Work Consulting GmbH
> >>
> >> Kriegsstr. 100 - 76133 Karlsruhe - Germany
> >> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
> >> karl.eilebrecht@key-work.de
> >>
> >>
> >> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> >> Geschäftsführer: Andreas Stappert, Tobin Wotring
> >>
> >>
> >
> >
> >
>

Re: AW: Ofbiz Contribution Proposal

[David E Jones <jo...@hotwaxmedia.com>]

Karl,

I see the issues you created: OFBIZ-1016 to OFBIZ-1033

I will be reviewing these over the next week or so.

NOTE FOR OTHER COMMITTERS: feel free to take a look at and comment on these, but I'd like to do a more thorough review of some of them as they appear to duplicate other functionality in the framework (some of which was probably developed after Karl implemented something similar for his needs).

-David



Eilebrecht, Karl (Key-Work) wrote:
> Hi,
> 
> I have finally split our work into several issues
> listed on 
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> 
> I hope the patches I created will work correctly.
> They're based on the trunk revision 540035.
> 
> Starting with JIRA-1016 some patches require others - means, you'll have
> to apply the required ones before.
> 
> Please have a look at the issues!
> 
> @Michael Imhoff: I found your patch JIRA-746 (now JIRA-1008)
> and integrated it into my patch (JIRA-1028).
> The conversion part has been extracted into a strategy class
> to allow individual type conversion by configuration.
> 
> Regards.
> Karl
> 
> -----Ursprüngliche Nachricht-----
> Von: David E. Jones [mailto:jonesde@hotwaxmedia.com] 
> Gesendet: Dienstag, 24. April 2007 09:35
> An: dev@ofbiz.apache.org
> Betreff: Re: AW: Ofbiz Contribution Proposal
> 
> 
> I agree with Chris here. This can happen in many steps, and the first  
> step doesn't have to be totally ready to go.
> 
> It's perfectly fine to submit stuff knowing (and saying) that it's  
> based on an older version or incomplete or in whatever way not  
> totally ready to go.
> 
> Whatever the case, without at least a preliminary submission nothing  
> can really happen outside of your group. And even if you're not ready  
> for a big investment to get this going, maybe someone else is.
> 
> BTW, in general all contributions (except bug fixes for a release  
> branch) should be against the trunk, and the most recent revision  
> possible. The main way we work together in OFBiz is working against  
> the trunk and collaborating to help the project move forward.
> 
> -David
> 
> 
> On Apr 24, 2007, at 1:13 AM, Chris Howe wrote:
> 
>> Hi Karl,
>>
>> I suspect there will be a lot of interest in what you're proposing.  A
>> bit more than the average "hey, I have an idea" Jira issue.  In
>> addition, most of what you described in your proposal appears rather
>> modular to the current code.  If I were in your position, I would open
>> a  Jira issue and attach a patch as you have it now.  If people start
>> playing with it they'll likely bring it in line with current code and
>> take care of the formatting issues.  If no one from the community  
>> picks
>> it up then you guys might consider modernizing it so that it's more
>> palatable.
>>
>> I say, just get it out there; see what the community can do with it.
>> If it's nothing, then deal with it. :-)
>>
>>
>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>  
>> wrote:
>>
>>> Chris, Jonathon, Jacques,
>>>
>>> thank you again for your time.
>>> As I understand there are some issues and obstacles related
>>> to contributing code to the community - especially complex ones.
>>>
>>> There are two parties, on the one hand people that like to share
>>> changes as soon as possible among each other and on the other hand
>>> those
>>> trying to keep Ofbiz a clean consistent project with reviewed code
>>> and
>>> free of third party rights.
>>> I can understand both sides. Although I was very happy with Jonathons
>>> idea of having someone with experience and the big picture to take
>>> our stuff for an initial review. Hmmpf ...
>>>
>>> However, alternative plan could be:
>>> - download the next release (whatever, whenever)
>>> - read that best-practice-document, ignoring the warnings about large
>>> contributions
>>> - merge-in our changes
>>> - test
>>> - split our work into rational parts and create JIRA-issues for these
>>> - make SVN-patches and attach them to the previously created issues
>>> - wait for feedback
>>>
>>> I'll discuss this again with my colleagues.
>>> This may take some days since I'm not always in the office in May as
>>> I mentioned before.
>>>
>>> Regards.
>>> Karl
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jonathon -- Improov [mailto:jonw@improov.com]
>>> Gesendet: Dienstag, 24. April 2007 05:00
>>> An: dev@ofbiz.apache.org
>>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>>
>>> Karl,
>>>
>>> David Jones is creating a release branch in minutes. Make sure you
>>> don't merge in a trunk revision
>>> AFTER the fork, but before.
>>>
>>> Or you can wait for the release branch, and pull it in for merge when
>>> it is published.
>>>
>>> Jonathon
>>>
>>> Jonathon -- Improov wrote:
>>>> Karl,
>>>>
>>>> First, if you can manage to break up your enhancements into cleanly
>>>> demarcated blocks, please do so, and also follow document at
>>>>
>> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best 
>> +Practices
>>>> . If not, we can proceed.
>>>>
>>>> I was assuming you couldn't give me a patch created from Jan 07
>>> OFBiz
>>>> revision (what's the rev number?) to your current work. If you can,
>>> then
>>>> just send me that patch, and skip the following. But if by any
>>> chance
>>>> the patch isn't valid (ie, you performed the diffs and merges
>>> wrongly),
>>>> we'll still have to revert to original plan.
>>>>
>>>>> As I understand first option is to send you two archives, one
>>> with the
>>>>> original distribution we downloaded in January and a second one
>>> also
>>>>> including our changes.
>>>> Yes. And if you can manage, please take out the 35MB of 3rd-party
>>>> binaries. Code binaries have no business living in SVN, actually.
>>> But
>>>> before you remove those binaries, please create an md5 manifest of
>>> all
>>>> these binaries. I'll need that manifest.
>>>>
>>>> Once you've taken out the 35MB binaries, the actual OFBiz codes
>>> should
>>>> compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo
>>> from
>>>> SVN as well, since the 4MB+ codes can be considered "3rd-party
>>> binaries".)
>>>> So you never did a merge-in of OFBiz updates into your work? You
>>> mean
>>>> you started your work from a Jan 07 OFBiz revision?
>>>>
>>>>> Second option is to download the next release (coming these
>>> days?),
>>>>> merge this and send you the pre-merged archive to do a check.
>>>> There is no next release, far as I can tell. If you're talking
>>> about the
>>>> release branch, I'd suggest you don't hold your breath. You can
>>> operate
>>>> with the trunk as well as you can with the "supposedly more stable"
>>>> release branch. A newly-born release branch is actually as unstable
>>> as
>>>> the trunk! Will take some time before the release branch matures to
>>>> release-standard quality.
>>>>
>>>> You can certainly pull in the latest OFBiz trunk revision (let's
>>> call
>>>> this "Start Revision") and perform the merge yourself, and then
>>> send me
>>>> the merged result. Still, let me know the exact revision number of
>>> this
>>>> "Start Revision". And please perform this risky wholesale merge on
>>> an
>>>> insulated exploratory branch in your repository.
>>>>
>>>> In that case, I will perform a quick compare between your work and
>>> the
>>>> "Start Revision". If by any chance you had performed the merge
>>>> incorrectly, we will still have to revert to the original plan.
>>>>
>>>>> I've got an account at
>>> https://issues.apache.org/jira/browse/OFBIZ
>>>>> Is it correct that I will have to attach a large archive to an
>>> issue
>>>>> created in advance by yourself or myself?
>>>> No, please don't attach an entire archive of your codes. It's
>>> better to
>>>> attach small deltas.
>>>>
>>>> You are free to create a new Jira issue, perhaps entitled "Karl's
>>> Big
>>>> Enhancements". It really is up to the community to discuss it or
>>> not.
>>>>> If you're going to create the initial issue (mentioned in your
>>> last
>>>> posting)
>>>>> please send me the issue number. I'll also put a link on that
>>> wiki page.
>>>> I think it's best that you create the Jira issue. Ultimately,
>>> you're the
>>>> contributor here. You'll need to do a "code grant" via Jira when
>>>> attaching your patch, so that you grant your work to the ASF. I
>>> can't do
>>>> it for you.
>>>>
>>>> And lastly, do know that I'm performing this merge for you for
>>> free, but
>>>> on condition that you put your contributions under the ASL 2.0. In
>>> the
>>>> worst case, I could be the only SVN that contains your enhancements
>>>> (aside from your own SVN), but at least I'll have them all under
>>> ASL 2.0.
>>>> Jonathon
>>>>
>>>> Eilebrecht, Karl (Key-Work) wrote:
>>>>> Jonathon,
>>>>>
>>>>> I'll discuss this with a colleague.
>>>>> As I understand first option is to send you two archives, one with
>>> the
>>>>> original distribution we
>>>>> downloaded in January and a second one also including
>>>>> our changes.
>>>>> Second option is to download the next release (coming these
>>> days?),
>>>>> merge this and send you the pre-merged archive to do a check.
>>>>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>>>>> Is it correct that I will have to attach a large archive to an
>>> issue
>>>>> created in advance by yourself or myself?
>>>>>
>>>>> If you're going to create the initial issue (mentioned in your
>>> last
>>>>> posting)
>>>>> please send me the issue number. I'll also put a link on that wiki
>>> page.
>>>>> Thanks for your support!
>>>>>
>>>>> Regards.
>>>>> Karl
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>> === message truncated ===
>>
> 

AW: Ofbiz Contribution Proposal

["Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>]

Hi,

I have finally split our work into several issues
listed on 
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal

I hope the patches I created will work correctly.
They're based on the trunk revision 540035.

Starting with JIRA-1016 some patches require others - means, you'll have
to apply the required ones before.

Please have a look at the issues!

@Michael Imhoff: I found your patch JIRA-746 (now JIRA-1008)
and integrated it into my patch (JIRA-1028).
The conversion part has been extracted into a strategy class
to allow individual type conversion by configuration.

Regards.
Karl

-----Ursprüngliche Nachricht-----
Von: David E. Jones [mailto:jonesde@hotwaxmedia.com] 
Gesendet: Dienstag, 24. April 2007 09:35
An: dev@ofbiz.apache.org
Betreff: Re: AW: Ofbiz Contribution Proposal


I agree with Chris here. This can happen in many steps, and the first  
step doesn't have to be totally ready to go.

It's perfectly fine to submit stuff knowing (and saying) that it's  
based on an older version or incomplete or in whatever way not  
totally ready to go.

Whatever the case, without at least a preliminary submission nothing  
can really happen outside of your group. And even if you're not ready  
for a big investment to get this going, maybe someone else is.

BTW, in general all contributions (except bug fixes for a release  
branch) should be against the trunk, and the most recent revision  
possible. The main way we work together in OFBiz is working against  
the trunk and collaborating to help the project move forward.

-David


On Apr 24, 2007, at 1:13 AM, Chris Howe wrote:

> Hi Karl,
>
> I suspect there will be a lot of interest in what you're proposing.  A
> bit more than the average "hey, I have an idea" Jira issue.  In
> addition, most of what you described in your proposal appears rather
> modular to the current code.  If I were in your position, I would open
> a  Jira issue and attach a patch as you have it now.  If people start
> playing with it they'll likely bring it in line with current code and
> take care of the formatting issues.  If no one from the community  
> picks
> it up then you guys might consider modernizing it so that it's more
> palatable.
>
> I say, just get it out there; see what the community can do with it.
> If it's nothing, then deal with it. :-)
>
>
> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>  
> wrote:
>
>> Chris, Jonathon, Jacques,
>>
>> thank you again for your time.
>> As I understand there are some issues and obstacles related
>> to contributing code to the community - especially complex ones.
>>
>> There are two parties, on the one hand people that like to share
>> changes as soon as possible among each other and on the other hand
>> those
>> trying to keep Ofbiz a clean consistent project with reviewed code
>> and
>> free of third party rights.
>> I can understand both sides. Although I was very happy with Jonathons
>> idea of having someone with experience and the big picture to take
>> our stuff for an initial review. Hmmpf ...
>>
>> However, alternative plan could be:
>> - download the next release (whatever, whenever)
>> - read that best-practice-document, ignoring the warnings about large
>> contributions
>> - merge-in our changes
>> - test
>> - split our work into rational parts and create JIRA-issues for these
>> - make SVN-patches and attach them to the previously created issues
>> - wait for feedback
>>
>> I'll discuss this again with my colleagues.
>> This may take some days since I'm not always in the office in May as
>> I mentioned before.
>>
>> Regards.
>> Karl
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jonathon -- Improov [mailto:jonw@improov.com]
>> Gesendet: Dienstag, 24. April 2007 05:00
>> An: dev@ofbiz.apache.org
>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>
>> Karl,
>>
>> David Jones is creating a release branch in minutes. Make sure you
>> don't merge in a trunk revision
>> AFTER the fork, but before.
>>
>> Or you can wait for the release branch, and pull it in for merge when
>> it is published.
>>
>> Jonathon
>>
>> Jonathon -- Improov wrote:
>>> Karl,
>>>
>>> First, if you can manage to break up your enhancements into cleanly
>>
>>> demarcated blocks, please do so, and also follow document at
>>>
>>
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best 
> +Practices
>>
>>> . If not, we can proceed.
>>>
>>> I was assuming you couldn't give me a patch created from Jan 07
>> OFBiz
>>> revision (what's the rev number?) to your current work. If you can,
>> then
>>> just send me that patch, and skip the following. But if by any
>> chance
>>> the patch isn't valid (ie, you performed the diffs and merges
>> wrongly),
>>> we'll still have to revert to original plan.
>>>
>>>> As I understand first option is to send you two archives, one
>> with the
>>>> original distribution we downloaded in January and a second one
>> also
>>>> including our changes.
>>>
>>> Yes. And if you can manage, please take out the 35MB of 3rd-party
>>> binaries. Code binaries have no business living in SVN, actually.
>> But
>>> before you remove those binaries, please create an md5 manifest of
>> all
>>> these binaries. I'll need that manifest.
>>>
>>> Once you've taken out the 35MB binaries, the actual OFBiz codes
>> should
>>> compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo
>> from
>>> SVN as well, since the 4MB+ codes can be considered "3rd-party
>> binaries".)
>>>
>>> So you never did a merge-in of OFBiz updates into your work? You
>> mean
>>> you started your work from a Jan 07 OFBiz revision?
>>>
>>>> Second option is to download the next release (coming these
>> days?),
>>>> merge this and send you the pre-merged archive to do a check.
>>>
>>> There is no next release, far as I can tell. If you're talking
>> about the
>>> release branch, I'd suggest you don't hold your breath. You can
>> operate
>>> with the trunk as well as you can with the "supposedly more stable"
>>
>>> release branch. A newly-born release branch is actually as unstable
>> as
>>> the trunk! Will take some time before the release branch matures to
>>
>>> release-standard quality.
>>>
>>> You can certainly pull in the latest OFBiz trunk revision (let's
>> call
>>> this "Start Revision") and perform the merge yourself, and then
>> send me
>>> the merged result. Still, let me know the exact revision number of
>> this
>>> "Start Revision". And please perform this risky wholesale merge on
>> an
>>> insulated exploratory branch in your repository.
>>>
>>> In that case, I will perform a quick compare between your work and
>> the
>>> "Start Revision". If by any chance you had performed the merge
>>> incorrectly, we will still have to revert to the original plan.
>>>
>>>> I've got an account at
>> https://issues.apache.org/jira/browse/OFBIZ
>>>> Is it correct that I will have to attach a large archive to an
>> issue
>>>> created in advance by yourself or myself?
>>>
>>> No, please don't attach an entire archive of your codes. It's
>> better to
>>> attach small deltas.
>>>
>>> You are free to create a new Jira issue, perhaps entitled "Karl's
>> Big
>>> Enhancements". It really is up to the community to discuss it or
>> not.
>>>
>>>> If you're going to create the initial issue (mentioned in your
>> last
>>> posting)
>>>> please send me the issue number. I'll also put a link on that
>> wiki page.
>>>
>>> I think it's best that you create the Jira issue. Ultimately,
>> you're the
>>> contributor here. You'll need to do a "code grant" via Jira when
>>> attaching your patch, so that you grant your work to the ASF. I
>> can't do
>>> it for you.
>>>
>>> And lastly, do know that I'm performing this merge for you for
>> free, but
>>> on condition that you put your contributions under the ASL 2.0. In
>> the
>>> worst case, I could be the only SVN that contains your enhancements
>>
>>> (aside from your own SVN), but at least I'll have them all under
>> ASL 2.0.
>>>
>>> Jonathon
>>>
>>> Eilebrecht, Karl (Key-Work) wrote:
>>>> Jonathon,
>>>>
>>>> I'll discuss this with a colleague.
>>>> As I understand first option is to send you two archives, one with
>> the
>>>> original distribution we
>>>> downloaded in January and a second one also including
>>>> our changes.
>>>> Second option is to download the next release (coming these
>> days?),
>>>> merge this and send you the pre-merged archive to do a check.
>>>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>>>> Is it correct that I will have to attach a large archive to an
>> issue
>>>> created in advance by yourself or myself?
>>>>
>>>> If you're going to create the initial issue (mentioned in your
>> last
>>>> posting)
>>>> please send me the issue number. I'll also put a link on that wiki
>> page.
>>>>
>>>> Thanks for your support!
>>>>
>>>> Regards.
>>>> Karl
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>
> === message truncated ===
>

-- 
Karl Eilebrecht
Key-Work Consulting GmbH

Kriegsstr. 100 - 76133 Karlsruhe - Germany
Fon: +49-721-78203-277 - Fax: +49-721-78203-10
karl.eilebrecht@key-work.de


Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
Geschäftsführer: Andreas Stappert, Tobin Wotring

Re: AW: Ofbiz Contribution Proposal

["David E. Jones" <jo...@hotwaxmedia.com>]

I agree with Chris here. This can happen in many steps, and the first  
step doesn't have to be totally ready to go.

It's perfectly fine to submit stuff knowing (and saying) that it's  
based on an older version or incomplete or in whatever way not  
totally ready to go.

Whatever the case, without at least a preliminary submission nothing  
can really happen outside of your group. And even if you're not ready  
for a big investment to get this going, maybe someone else is.

BTW, in general all contributions (except bug fixes for a release  
branch) should be against the trunk, and the most recent revision  
possible. The main way we work together in OFBiz is working against  
the trunk and collaborating to help the project move forward.

-David


On Apr 24, 2007, at 1:13 AM, Chris Howe wrote:

> Hi Karl,
>
> I suspect there will be a lot of interest in what you're proposing.  A
> bit more than the average "hey, I have an idea" Jira issue.  In
> addition, most of what you described in your proposal appears rather
> modular to the current code.  If I were in your position, I would open
> a  Jira issue and attach a patch as you have it now.  If people start
> playing with it they'll likely bring it in line with current code and
> take care of the formatting issues.  If no one from the community  
> picks
> it up then you guys might consider modernizing it so that it's more
> palatable.
>
> I say, just get it out there; see what the community can do with it.
> If it's nothing, then deal with it. :-)
>
>
> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>  
> wrote:
>
>> Chris, Jonathon, Jacques,
>>
>> thank you again for your time.
>> As I understand there are some issues and obstacles related
>> to contributing code to the community - especially complex ones.
>>
>> There are two parties, on the one hand people that like to share
>> changes as soon as possible among each other and on the other hand
>> those
>> trying to keep Ofbiz a clean consistent project with reviewed code
>> and
>> free of third party rights.
>> I can understand both sides. Although I was very happy with Jonathons
>> idea of having someone with experience and the big picture to take
>> our stuff for an initial review. Hmmpf ...
>>
>> However, alternative plan could be:
>> - download the next release (whatever, whenever)
>> - read that best-practice-document, ignoring the warnings about large
>> contributions
>> - merge-in our changes
>> - test
>> - split our work into rational parts and create JIRA-issues for these
>> - make SVN-patches and attach them to the previously created issues
>> - wait for feedback
>>
>> I'll discuss this again with my colleagues.
>> This may take some days since I'm not always in the office in May as
>> I mentioned before.
>>
>> Regards.
>> Karl
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jonathon -- Improov [mailto:jonw@improov.com]
>> Gesendet: Dienstag, 24. April 2007 05:00
>> An: dev@ofbiz.apache.org
>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>
>> Karl,
>>
>> David Jones is creating a release branch in minutes. Make sure you
>> don't merge in a trunk revision
>> AFTER the fork, but before.
>>
>> Or you can wait for the release branch, and pull it in for merge when
>> it is published.
>>
>> Jonathon
>>
>> Jonathon -- Improov wrote:
>>> Karl,
>>>
>>> First, if you can manage to break up your enhancements into cleanly
>>
>>> demarcated blocks, please do so, and also follow document at
>>>
>>
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best 
> +Practices
>>
>>> . If not, we can proceed.
>>>
>>> I was assuming you couldn't give me a patch created from Jan 07
>> OFBiz
>>> revision (what's the rev number?) to your current work. If you can,
>> then
>>> just send me that patch, and skip the following. But if by any
>> chance
>>> the patch isn't valid (ie, you performed the diffs and merges
>> wrongly),
>>> we'll still have to revert to original plan.
>>>
>>>> As I understand first option is to send you two archives, one
>> with the
>>>> original distribution we downloaded in January and a second one
>> also
>>>> including our changes.
>>>
>>> Yes. And if you can manage, please take out the 35MB of 3rd-party
>>> binaries. Code binaries have no business living in SVN, actually.
>> But
>>> before you remove those binaries, please create an md5 manifest of
>> all
>>> these binaries. I'll need that manifest.
>>>
>>> Once you've taken out the 35MB binaries, the actual OFBiz codes
>> should
>>> compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo
>> from
>>> SVN as well, since the 4MB+ codes can be considered "3rd-party
>> binaries".)
>>>
>>> So you never did a merge-in of OFBiz updates into your work? You
>> mean
>>> you started your work from a Jan 07 OFBiz revision?
>>>
>>>> Second option is to download the next release (coming these
>> days?),
>>>> merge this and send you the pre-merged archive to do a check.
>>>
>>> There is no next release, far as I can tell. If you're talking
>> about the
>>> release branch, I'd suggest you don't hold your breath. You can
>> operate
>>> with the trunk as well as you can with the "supposedly more stable"
>>
>>> release branch. A newly-born release branch is actually as unstable
>> as
>>> the trunk! Will take some time before the release branch matures to
>>
>>> release-standard quality.
>>>
>>> You can certainly pull in the latest OFBiz trunk revision (let's
>> call
>>> this "Start Revision") and perform the merge yourself, and then
>> send me
>>> the merged result. Still, let me know the exact revision number of
>> this
>>> "Start Revision". And please perform this risky wholesale merge on
>> an
>>> insulated exploratory branch in your repository.
>>>
>>> In that case, I will perform a quick compare between your work and
>> the
>>> "Start Revision". If by any chance you had performed the merge
>>> incorrectly, we will still have to revert to the original plan.
>>>
>>>> I've got an account at
>> https://issues.apache.org/jira/browse/OFBIZ
>>>> Is it correct that I will have to attach a large archive to an
>> issue
>>>> created in advance by yourself or myself?
>>>
>>> No, please don't attach an entire archive of your codes. It's
>> better to
>>> attach small deltas.
>>>
>>> You are free to create a new Jira issue, perhaps entitled "Karl's
>> Big
>>> Enhancements". It really is up to the community to discuss it or
>> not.
>>>
>>>> If you're going to create the initial issue (mentioned in your
>> last
>>> posting)
>>>> please send me the issue number. I'll also put a link on that
>> wiki page.
>>>
>>> I think it's best that you create the Jira issue. Ultimately,
>> you're the
>>> contributor here. You'll need to do a "code grant" via Jira when
>>> attaching your patch, so that you grant your work to the ASF. I
>> can't do
>>> it for you.
>>>
>>> And lastly, do know that I'm performing this merge for you for
>> free, but
>>> on condition that you put your contributions under the ASL 2.0. In
>> the
>>> worst case, I could be the only SVN that contains your enhancements
>>
>>> (aside from your own SVN), but at least I'll have them all under
>> ASL 2.0.
>>>
>>> Jonathon
>>>
>>> Eilebrecht, Karl (Key-Work) wrote:
>>>> Jonathon,
>>>>
>>>> I'll discuss this with a colleague.
>>>> As I understand first option is to send you two archives, one with
>> the
>>>> original distribution we
>>>> downloaded in January and a second one also including
>>>> our changes.
>>>> Second option is to download the next release (coming these
>> days?),
>>>> merge this and send you the pre-merged archive to do a check.
>>>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>>>> Is it correct that I will have to attach a large archive to an
>> issue
>>>> created in advance by yourself or myself?
>>>>
>>>> If you're going to create the initial issue (mentioned in your
>> last
>>>> posting)
>>>> please send me the issue number. I'll also put a link on that wiki
>> page.
>>>>
>>>> Thanks for your support!
>>>>
>>>> Regards.
>>>> Karl
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>
> === message truncated ===
>

Re: AW: Ofbiz Contribution Proposal

[Chris Howe <cj...@yahoo.com>]

Hi Karl,

I suspect there will be a lot of interest in what you're proposing.  A
bit more than the average "hey, I have an idea" Jira issue.  In
addition, most of what you described in your proposal appears rather
modular to the current code.  If I were in your position, I would open
a  Jira issue and attach a patch as you have it now.  If people start
playing with it they'll likely bring it in line with current code and
take care of the formatting issues.  If no one from the community picks
it up then you guys might consider modernizing it so that it's more
palatable.

I say, just get it out there; see what the community can do with it. 
If it's nothing, then deal with it. :-)


--- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:

> Chris, Jonathon, Jacques,
> 
> thank you again for your time.
> As I understand there are some issues and obstacles related
> to contributing code to the community - especially complex ones.
> 
> There are two parties, on the one hand people that like to share
> changes as soon as possible among each other and on the other hand
> those
> trying to keep Ofbiz a clean consistent project with reviewed code
> and
> free of third party rights.
> I can understand both sides. Although I was very happy with Jonathons
> idea of having someone with experience and the big picture to take
> our stuff for an initial review. Hmmpf ...
> 
> However, alternative plan could be:
> - download the next release (whatever, whenever)
> - read that best-practice-document, ignoring the warnings about large
> contributions
> - merge-in our changes
> - test
> - split our work into rational parts and create JIRA-issues for these
> - make SVN-patches and attach them to the previously created issues
> - wait for feedback 
> 
> I'll discuss this again with my colleagues.
> This may take some days since I'm not always in the office in May as
> I mentioned before.
> 
> Regards.
> Karl
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Jonathon -- Improov [mailto:jonw@improov.com] 
> Gesendet: Dienstag, 24. April 2007 05:00
> An: dev@ofbiz.apache.org
> Betreff: Re: AW: Ofbiz Contribution Proposal
> 
> Karl,
> 
> David Jones is creating a release branch in minutes. Make sure you
> don't merge in a trunk revision 
> AFTER the fork, but before.
> 
> Or you can wait for the release branch, and pull it in for merge when
> it is published.
> 
> Jonathon
> 
> Jonathon -- Improov wrote:
> > Karl,
> > 
> > First, if you can manage to break up your enhancements into cleanly
> 
> > demarcated blocks, please do so, and also follow document at 
> >
>
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> 
> > . If not, we can proceed.
> > 
> > I was assuming you couldn't give me a patch created from Jan 07
> OFBiz 
> > revision (what's the rev number?) to your current work. If you can,
> then 
> > just send me that patch, and skip the following. But if by any
> chance 
> > the patch isn't valid (ie, you performed the diffs and merges
> wrongly), 
> > we'll still have to revert to original plan.
> > 
> >  > As I understand first option is to send you two archives, one
> with the
> >  > original distribution we downloaded in January and a second one
> also
> >  > including our changes.
> > 
> > Yes. And if you can manage, please take out the 35MB of 3rd-party 
> > binaries. Code binaries have no business living in SVN, actually.
> But 
> > before you remove those binaries, please create an md5 manifest of
> all 
> > these binaries. I'll need that manifest.
> > 
> > Once you've taken out the 35MB binaries, the actual OFBiz codes
> should 
> > compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo
> from 
> > SVN as well, since the 4MB+ codes can be considered "3rd-party
> binaries".)
> > 
> > So you never did a merge-in of OFBiz updates into your work? You
> mean 
> > you started your work from a Jan 07 OFBiz revision?
> > 
> >  > Second option is to download the next release (coming these
> days?),
> >  > merge this and send you the pre-merged archive to do a check.
> > 
> > There is no next release, far as I can tell. If you're talking
> about the 
> > release branch, I'd suggest you don't hold your breath. You can
> operate 
> > with the trunk as well as you can with the "supposedly more stable"
> 
> > release branch. A newly-born release branch is actually as unstable
> as 
> > the trunk! Will take some time before the release branch matures to
> 
> > release-standard quality.
> > 
> > You can certainly pull in the latest OFBiz trunk revision (let's
> call 
> > this "Start Revision") and perform the merge yourself, and then
> send me 
> > the merged result. Still, let me know the exact revision number of
> this 
> > "Start Revision". And please perform this risky wholesale merge on
> an 
> > insulated exploratory branch in your repository.
> > 
> > In that case, I will perform a quick compare between your work and
> the 
> > "Start Revision". If by any chance you had performed the merge 
> > incorrectly, we will still have to revert to the original plan.
> > 
> >  > I've got an account at
> https://issues.apache.org/jira/browse/OFBIZ
> >  > Is it correct that I will have to attach a large archive to an
> issue
> >  > created in advance by yourself or myself?
> > 
> > No, please don't attach an entire archive of your codes. It's
> better to 
> > attach small deltas.
> > 
> > You are free to create a new Jira issue, perhaps entitled "Karl's
> Big 
> > Enhancements". It really is up to the community to discuss it or
> not.
> > 
> >  > If you're going to create the initial issue (mentioned in your
> last 
> > posting)
> >  > please send me the issue number. I'll also put a link on that
> wiki page.
> > 
> > I think it's best that you create the Jira issue. Ultimately,
> you're the 
> > contributor here. You'll need to do a "code grant" via Jira when 
> > attaching your patch, so that you grant your work to the ASF. I
> can't do 
> > it for you.
> > 
> > And lastly, do know that I'm performing this merge for you for
> free, but 
> > on condition that you put your contributions under the ASL 2.0. In
> the 
> > worst case, I could be the only SVN that contains your enhancements
> 
> > (aside from your own SVN), but at least I'll have them all under
> ASL 2.0.
> > 
> > Jonathon
> > 
> > Eilebrecht, Karl (Key-Work) wrote:
> >> Jonathon,
> >>
> >> I'll discuss this with a colleague.
> >> As I understand first option is to send you two archives, one with
> the 
> >> original distribution we
> >> downloaded in January and a second one also including
> >> our changes.
> >> Second option is to download the next release (coming these
> days?), 
> >> merge this and send you the pre-merged archive to do a check.
> >> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
> >> Is it correct that I will have to attach a large archive to an
> issue
> >> created in advance by yourself or myself?
> >>
> >> If you're going to create the initial issue (mentioned in your
> last 
> >> posting)
> >> please send me the issue number. I'll also put a link on that wiki
> page.
> >>
> >> Thanks for your support!
> >>
> >> Regards.
> >> Karl
> >>
> >>
> >>
> >>
> >>
> >> -----Ursprüngliche Nachricht-----
> 
=== message truncated ===

AW: Ofbiz Contribution Proposal

["Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>]

Chris, Jonathon, Jacques,

thank you again for your time.
As I understand there are some issues and obstacles related
to contributing code to the community - especially complex ones.

There are two parties, on the one hand people that like to share
changes as soon as possible among each other and on the other hand those
trying to keep Ofbiz a clean consistent project with reviewed code and
free of third party rights.
I can understand both sides. Although I was very happy with Jonathons
idea of having someone with experience and the big picture to take
our stuff for an initial review. Hmmpf ...

However, alternative plan could be:
- download the next release (whatever, whenever)
- read that best-practice-document, ignoring the warnings about large contributions
- merge-in our changes
- test
- split our work into rational parts and create JIRA-issues for these
- make SVN-patches and attach them to the previously created issues
- wait for feedback 

I'll discuss this again with my colleagues.
This may take some days since I'm not always in the office in May as I mentioned before.

Regards.
Karl




-----Ursprüngliche Nachricht-----
Von: Jonathon -- Improov [mailto:jonw@improov.com] 
Gesendet: Dienstag, 24. April 2007 05:00
An: dev@ofbiz.apache.org
Betreff: Re: AW: Ofbiz Contribution Proposal

Karl,

David Jones is creating a release branch in minutes. Make sure you don't merge in a trunk revision 
AFTER the fork, but before.

Or you can wait for the release branch, and pull it in for merge when it is published.

Jonathon

Jonathon -- Improov wrote:
> Karl,
> 
> First, if you can manage to break up your enhancements into cleanly 
> demarcated blocks, please do so, and also follow document at 
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices 
> . If not, we can proceed.
> 
> I was assuming you couldn't give me a patch created from Jan 07 OFBiz 
> revision (what's the rev number?) to your current work. If you can, then 
> just send me that patch, and skip the following. But if by any chance 
> the patch isn't valid (ie, you performed the diffs and merges wrongly), 
> we'll still have to revert to original plan.
> 
>  > As I understand first option is to send you two archives, one with the
>  > original distribution we downloaded in January and a second one also
>  > including our changes.
> 
> Yes. And if you can manage, please take out the 35MB of 3rd-party 
> binaries. Code binaries have no business living in SVN, actually. But 
> before you remove those binaries, please create an md5 manifest of all 
> these binaries. I'll need that manifest.
> 
> Once you've taken out the 35MB binaries, the actual OFBiz codes should 
> compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo from 
> SVN as well, since the 4MB+ codes can be considered "3rd-party binaries".)
> 
> So you never did a merge-in of OFBiz updates into your work? You mean 
> you started your work from a Jan 07 OFBiz revision?
> 
>  > Second option is to download the next release (coming these days?),
>  > merge this and send you the pre-merged archive to do a check.
> 
> There is no next release, far as I can tell. If you're talking about the 
> release branch, I'd suggest you don't hold your breath. You can operate 
> with the trunk as well as you can with the "supposedly more stable" 
> release branch. A newly-born release branch is actually as unstable as 
> the trunk! Will take some time before the release branch matures to 
> release-standard quality.
> 
> You can certainly pull in the latest OFBiz trunk revision (let's call 
> this "Start Revision") and perform the merge yourself, and then send me 
> the merged result. Still, let me know the exact revision number of this 
> "Start Revision". And please perform this risky wholesale merge on an 
> insulated exploratory branch in your repository.
> 
> In that case, I will perform a quick compare between your work and the 
> "Start Revision". If by any chance you had performed the merge 
> incorrectly, we will still have to revert to the original plan.
> 
>  > I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>  > Is it correct that I will have to attach a large archive to an issue
>  > created in advance by yourself or myself?
> 
> No, please don't attach an entire archive of your codes. It's better to 
> attach small deltas.
> 
> You are free to create a new Jira issue, perhaps entitled "Karl's Big 
> Enhancements". It really is up to the community to discuss it or not.
> 
>  > If you're going to create the initial issue (mentioned in your last 
> posting)
>  > please send me the issue number. I'll also put a link on that wiki page.
> 
> I think it's best that you create the Jira issue. Ultimately, you're the 
> contributor here. You'll need to do a "code grant" via Jira when 
> attaching your patch, so that you grant your work to the ASF. I can't do 
> it for you.
> 
> And lastly, do know that I'm performing this merge for you for free, but 
> on condition that you put your contributions under the ASL 2.0. In the 
> worst case, I could be the only SVN that contains your enhancements 
> (aside from your own SVN), but at least I'll have them all under ASL 2.0.
> 
> Jonathon
> 
> Eilebrecht, Karl (Key-Work) wrote:
>> Jonathon,
>>
>> I'll discuss this with a colleague.
>> As I understand first option is to send you two archives, one with the 
>> original distribution we
>> downloaded in January and a second one also including
>> our changes.
>> Second option is to download the next release (coming these days?), 
>> merge this and send you the pre-merged archive to do a check.
>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>> Is it correct that I will have to attach a large archive to an issue
>> created in advance by yourself or myself?
>>
>> If you're going to create the initial issue (mentioned in your last 
>> posting)
>> please send me the issue number. I'll also put a link on that wiki page.
>>
>> Thanks for your support!
>>
>> Regards.
>> Karl
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jonathon -- Improov [mailto:jonw@improov.com] Gesendet: Montag, 
>> 23. April 2007 13:38
>> An: dev@ofbiz.apache.org
>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>
>> Karl,
>>
>> It's a great offer on your part too, to let us have those codes!
>>
>> If you've done a merge with OFBiz trunk on 2007-01-05, that means you 
>> already know how to keep in step with OFBiz trunk head! You can 
>> actually do what I do, on your own.
>>
>> That said, if you still need my help, see the following.
>>
>> These are what I'll need from you:
>>
>> a. Exact OFBiz revision you started off from.
>>
>>     (Try to send me a tarball of that revision so I don't have to do a 
>> SVN
>>     download which can be a real pain thanks to the 35MB of 3rd-party
>>     libraries. My own SVN doesn't include those 35MB or 3rd-party 
>> binaries; let
>>     me know if you want advise on how to cut a lean SVN without 
>> binaries.)
>>
>> b. Tarball of your latest work you want merged with OFBiz trunk head.
>>
>> (Please do an "export"; I don't need the .cvs files.)
>>
>> What I will give you is a tarball of this: OFBiz trunk head (I'll 
>> state revision for our reference) married with the latest of your work.
>>
>> You will have to test this tarball over time, get back to me about 
>> problems, and I'll keep sending you fixed tarballs (or deltas, 
>> rather). We won't even have to touch the official OFBiz SVN.
>>
>> For the initial "review", I will at least make sure it compiles and 
>> runs. You will have to test your own functions to see they still work 
>> with the latest updates from OFBiz SVN.
>>
>> So, here's the summary of the process:
>>
>> 1. We merge latest of OFBiz with your stuff.
>>
>> 2. Review A: We make sure your stuff still works.
>>
>> 3. Review B: We (or community) make sure the general OFBiz stuff still 
>> works.
>>
>> 4. We submit a patch (diff OFBiz to Your_work) to community.
>>
>> And then the ball will be in their (committers') court.
>>
>> Generally, you can pretty much stop at step 2 if all you want is the 
>> latest of OFBiz working with your stuff. If you had done your 
>> customizations in a backward-compatible manner, step 3 won't be very 
>> difficult or even necessary at all.
>>
>> Jonathon
>>
>> Eilebrecht, Karl (Key-Work) wrote:
>>> Hi Jonathan, hi Chris,
>>>
>>> thank you for your feedback (and also thank you for stiring up a 
>>> hornet's nest ;-) )
>>>
>>> @Chris: I will try to answer your questions on the wiki page:
>>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>> I think this is more comfortable to retrace.
>>>
>>> @Jonathan: It's a great offer you made to take a look on our code and to
>>> evtl. merge it! What's the best way to provide the code to you?
>>> I'll have to prepare some things before:
>>> - for historical reasons we have a CVS repository and I
>>> or one of my colleagues will set up an SVN client. Is it more 
>>> convenient to
>>> you to get an archive for the first review or would you recommend to 
>>> pump the sources into a repository? (where?)
>>> - I already have added the Apache-Header (ASL) to all of the classes
>>> we might contribute.
>>> - I'll have to replace all tabs in the sources by 4 spaces.
>>>
>>> The rest I think should be not too complex, our last framework merge 
>>> (with trunk) was on 2007-01-05, I don't think there are dramatic low 
>>> level interface changes since then.
>>>
>>> We have already switched to Java 6 but all the classes to be contributed
>>> are compileable with Java 1.4.
>>>
>>> Regards.
>>> Karl
>>>
>>> BTW: During the next weeks there may be some "communication delays" 
>>> because I'll not be in the office all the time. So please don't worry 
>>> if an email answer needs some days, thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com] Gesendet: Samstag, 21. 
>>> April 2007 08:33
>>> An: dev@ofbiz.apache.org
>>> Betreff: Re: Ofbiz Contribution Proposal
>>>
>>> Hi Karl,
>>>
>>> I had the opportunity today to quickly read over your introductions.
>>> And must say it looks very interesting.  Unfortunately, for my being
>>> able to add input to the process, the improvements are in areas as an
>>> OFBiz user, that I take for granted and don't really get my hands dirty
>>> with.
>>> I'll need to read over the transaction part again to ask any
>>> intelligent questions, so I'll leave that for later.
>>>
>>> The custom SQL stuff looked very interesting and probably one of the
>>> larger areas of benefit as more and more people are getting to the
>>> point of locating bottlenecks in their applications.  I was wondering
>>> if there might be some benefit in encapsulating the stored sql
>>> statements it in an XML structure to be able to better take advantage
>>> of some META data/commenting that you discussed as well as potential of
>>> some reusability and structuring of those custom statements.
>>>
>>> Perhaps, I need to reread the logging discussion again, and ask if this
>>> is largely supported among other databases, but can't most of these
>>> logging of the sql statements be handled in the database's log, if
>>> configured to do so?  I recall a mention that the developer may not
>>> have sufficient access to the database server to ascertain the database
>>> logs...is this case where the logging proposal would be more
>>> beneficial?
>>>
>>> Thank you and Key-Work very much for bringing these enhancements back
>>> to the community!
>>>
>>> Chris
>>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
>>>
>>>> Hi,
>>>>
>>>>  
>>>>
>>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>>
>>>>  
>>>>
>>>> Last year I had mail contact with David.
>>>>
>>>>  
>>>>
>>>> He recommended to contribute changes to the Ofbiz Community regularly
>>>> whenever possible and useful.
>>>>  
>>>>
>>>> It is a long time since this happened, but we finally convinced our
>>>> management to try
>>>>
>>>>  
>>>>
>>>> to contribute some changes and extensions to the Ofbiz community.
>>>>
>>>>  
>>>>
>>>> I read the FAQ and found out that especially complex changes might
>>>> take a long time
>>>>
>>>>  
>>>>
>>>> and we may need some "community attendance".
>>>>
>>>>  
>>>>
>>>> David told me to place our proposal at the Ofbiz-WIKI
>>>>
>>>> and to send a link to this mailing list. 
>>>>  
>>>>
>>>> This is our "trial balloon" to find out whether our changes and
>>>> improvements
>>>>
>>>>  
>>>>
>>>> are welcome and how we could integrate them during the next months.
>>>>  
>>>>
>>>> I.e. the following extensions may also be interesting for other
>>>> members
>>>> of the community:
>>>>
>>>>  
>>>>
>>>>  * Advanced custom SQL integration
>>>>  * advanced sorting (locale, collation, natural sort)
>>>>  * completely refactored TransactionUtil with documentation and hints
>>>>
>>>>
>>>>  * on-demand "real"-sql-logging for ALL ofbiz statements
>>>> ...
>>>>  
>>>>
>>>> I placed our stuff at
>>>>
>>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>>> and hope one of the "Ofbiz gurus" will have a look at the attached
>>>> stuff to make a statement.
>>>>
>>>>  
>>>>
>>>> Thank you in advance!
>>>>
>>>>  
>>>>
>>>> Best regards
>>>>
>>>>  
>>>>
>>>> Karl Eilebrecht
>>>>
>>>> -- 
>>>> Karl Eilebrecht
>>>> Key-Work Consulting GmbH
>>>>
>>>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>>>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>>>> karl.eilebrecht@key-work.de
>>>>
>>>>
>>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>>
>>>>
>>>
>>>
>>
>>
>>
> 
> 

Re: AW: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Karl,

David Jones is creating a release branch in minutes. Make sure you don't merge in a trunk revision 
AFTER the fork, but before.

Or you can wait for the release branch, and pull it in for merge when it is published.

Jonathon

Jonathon -- Improov wrote:
> Karl,
> 
> First, if you can manage to break up your enhancements into cleanly 
> demarcated blocks, please do so, and also follow document at 
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices 
> . If not, we can proceed.
> 
> I was assuming you couldn't give me a patch created from Jan 07 OFBiz 
> revision (what's the rev number?) to your current work. If you can, then 
> just send me that patch, and skip the following. But if by any chance 
> the patch isn't valid (ie, you performed the diffs and merges wrongly), 
> we'll still have to revert to original plan.
> 
>  > As I understand first option is to send you two archives, one with the
>  > original distribution we downloaded in January and a second one also
>  > including our changes.
> 
> Yes. And if you can manage, please take out the 35MB of 3rd-party 
> binaries. Code binaries have no business living in SVN, actually. But 
> before you remove those binaries, please create an md5 manifest of all 
> these binaries. I'll need that manifest.
> 
> Once you've taken out the 35MB binaries, the actual OFBiz codes should 
> compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo from 
> SVN as well, since the 4MB+ codes can be considered "3rd-party binaries".)
> 
> So you never did a merge-in of OFBiz updates into your work? You mean 
> you started your work from a Jan 07 OFBiz revision?
> 
>  > Second option is to download the next release (coming these days?),
>  > merge this and send you the pre-merged archive to do a check.
> 
> There is no next release, far as I can tell. If you're talking about the 
> release branch, I'd suggest you don't hold your breath. You can operate 
> with the trunk as well as you can with the "supposedly more stable" 
> release branch. A newly-born release branch is actually as unstable as 
> the trunk! Will take some time before the release branch matures to 
> release-standard quality.
> 
> You can certainly pull in the latest OFBiz trunk revision (let's call 
> this "Start Revision") and perform the merge yourself, and then send me 
> the merged result. Still, let me know the exact revision number of this 
> "Start Revision". And please perform this risky wholesale merge on an 
> insulated exploratory branch in your repository.
> 
> In that case, I will perform a quick compare between your work and the 
> "Start Revision". If by any chance you had performed the merge 
> incorrectly, we will still have to revert to the original plan.
> 
>  > I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>  > Is it correct that I will have to attach a large archive to an issue
>  > created in advance by yourself or myself?
> 
> No, please don't attach an entire archive of your codes. It's better to 
> attach small deltas.
> 
> You are free to create a new Jira issue, perhaps entitled "Karl's Big 
> Enhancements". It really is up to the community to discuss it or not.
> 
>  > If you're going to create the initial issue (mentioned in your last 
> posting)
>  > please send me the issue number. I'll also put a link on that wiki page.
> 
> I think it's best that you create the Jira issue. Ultimately, you're the 
> contributor here. You'll need to do a "code grant" via Jira when 
> attaching your patch, so that you grant your work to the ASF. I can't do 
> it for you.
> 
> And lastly, do know that I'm performing this merge for you for free, but 
> on condition that you put your contributions under the ASL 2.0. In the 
> worst case, I could be the only SVN that contains your enhancements 
> (aside from your own SVN), but at least I'll have them all under ASL 2.0.
> 
> Jonathon
> 
> Eilebrecht, Karl (Key-Work) wrote:
>> Jonathon,
>>
>> I'll discuss this with a colleague.
>> As I understand first option is to send you two archives, one with the 
>> original distribution we
>> downloaded in January and a second one also including
>> our changes.
>> Second option is to download the next release (coming these days?), 
>> merge this and send you the pre-merged archive to do a check.
>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>> Is it correct that I will have to attach a large archive to an issue
>> created in advance by yourself or myself?
>>
>> If you're going to create the initial issue (mentioned in your last 
>> posting)
>> please send me the issue number. I'll also put a link on that wiki page.
>>
>> Thanks for your support!
>>
>> Regards.
>> Karl
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jonathon -- Improov [mailto:jonw@improov.com] Gesendet: Montag, 
>> 23. April 2007 13:38
>> An: dev@ofbiz.apache.org
>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>
>> Karl,
>>
>> It's a great offer on your part too, to let us have those codes!
>>
>> If you've done a merge with OFBiz trunk on 2007-01-05, that means you 
>> already know how to keep in step with OFBiz trunk head! You can 
>> actually do what I do, on your own.
>>
>> That said, if you still need my help, see the following.
>>
>> These are what I'll need from you:
>>
>> a. Exact OFBiz revision you started off from.
>>
>>     (Try to send me a tarball of that revision so I don't have to do a 
>> SVN
>>     download which can be a real pain thanks to the 35MB of 3rd-party
>>     libraries. My own SVN doesn't include those 35MB or 3rd-party 
>> binaries; let
>>     me know if you want advise on how to cut a lean SVN without 
>> binaries.)
>>
>> b. Tarball of your latest work you want merged with OFBiz trunk head.
>>
>> (Please do an "export"; I don't need the .cvs files.)
>>
>> What I will give you is a tarball of this: OFBiz trunk head (I'll 
>> state revision for our reference) married with the latest of your work.
>>
>> You will have to test this tarball over time, get back to me about 
>> problems, and I'll keep sending you fixed tarballs (or deltas, 
>> rather). We won't even have to touch the official OFBiz SVN.
>>
>> For the initial "review", I will at least make sure it compiles and 
>> runs. You will have to test your own functions to see they still work 
>> with the latest updates from OFBiz SVN.
>>
>> So, here's the summary of the process:
>>
>> 1. We merge latest of OFBiz with your stuff.
>>
>> 2. Review A: We make sure your stuff still works.
>>
>> 3. Review B: We (or community) make sure the general OFBiz stuff still 
>> works.
>>
>> 4. We submit a patch (diff OFBiz to Your_work) to community.
>>
>> And then the ball will be in their (committers') court.
>>
>> Generally, you can pretty much stop at step 2 if all you want is the 
>> latest of OFBiz working with your stuff. If you had done your 
>> customizations in a backward-compatible manner, step 3 won't be very 
>> difficult or even necessary at all.
>>
>> Jonathon
>>
>> Eilebrecht, Karl (Key-Work) wrote:
>>> Hi Jonathan, hi Chris,
>>>
>>> thank you for your feedback (and also thank you for stiring up a 
>>> hornet's nest ;-) )
>>>
>>> @Chris: I will try to answer your questions on the wiki page:
>>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>> I think this is more comfortable to retrace.
>>>
>>> @Jonathan: It's a great offer you made to take a look on our code and to
>>> evtl. merge it! What's the best way to provide the code to you?
>>> I'll have to prepare some things before:
>>> - for historical reasons we have a CVS repository and I
>>> or one of my colleagues will set up an SVN client. Is it more 
>>> convenient to
>>> you to get an archive for the first review or would you recommend to 
>>> pump the sources into a repository? (where?)
>>> - I already have added the Apache-Header (ASL) to all of the classes
>>> we might contribute.
>>> - I'll have to replace all tabs in the sources by 4 spaces.
>>>
>>> The rest I think should be not too complex, our last framework merge 
>>> (with trunk) was on 2007-01-05, I don't think there are dramatic low 
>>> level interface changes since then.
>>>
>>> We have already switched to Java 6 but all the classes to be contributed
>>> are compileable with Java 1.4.
>>>
>>> Regards.
>>> Karl
>>>
>>> BTW: During the next weeks there may be some "communication delays" 
>>> because I'll not be in the office all the time. So please don't worry 
>>> if an email answer needs some days, thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com] Gesendet: Samstag, 21. 
>>> April 2007 08:33
>>> An: dev@ofbiz.apache.org
>>> Betreff: Re: Ofbiz Contribution Proposal
>>>
>>> Hi Karl,
>>>
>>> I had the opportunity today to quickly read over your introductions.
>>> And must say it looks very interesting.  Unfortunately, for my being
>>> able to add input to the process, the improvements are in areas as an
>>> OFBiz user, that I take for granted and don't really get my hands dirty
>>> with.
>>> I'll need to read over the transaction part again to ask any
>>> intelligent questions, so I'll leave that for later.
>>>
>>> The custom SQL stuff looked very interesting and probably one of the
>>> larger areas of benefit as more and more people are getting to the
>>> point of locating bottlenecks in their applications.  I was wondering
>>> if there might be some benefit in encapsulating the stored sql
>>> statements it in an XML structure to be able to better take advantage
>>> of some META data/commenting that you discussed as well as potential of
>>> some reusability and structuring of those custom statements.
>>>
>>> Perhaps, I need to reread the logging discussion again, and ask if this
>>> is largely supported among other databases, but can't most of these
>>> logging of the sql statements be handled in the database's log, if
>>> configured to do so?  I recall a mention that the developer may not
>>> have sufficient access to the database server to ascertain the database
>>> logs...is this case where the logging proposal would be more
>>> beneficial?
>>>
>>> Thank you and Key-Work very much for bringing these enhancements back
>>> to the community!
>>>
>>> Chris
>>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
>>>
>>>> Hi,
>>>>
>>>>  
>>>>
>>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>>
>>>>  
>>>>
>>>> Last year I had mail contact with David.
>>>>
>>>>  
>>>>
>>>> He recommended to contribute changes to the Ofbiz Community regularly
>>>> whenever possible and useful.
>>>>  
>>>>
>>>> It is a long time since this happened, but we finally convinced our
>>>> management to try
>>>>
>>>>  
>>>>
>>>> to contribute some changes and extensions to the Ofbiz community.
>>>>
>>>>  
>>>>
>>>> I read the FAQ and found out that especially complex changes might
>>>> take a long time
>>>>
>>>>  
>>>>
>>>> and we may need some "community attendance".
>>>>
>>>>  
>>>>
>>>> David told me to place our proposal at the Ofbiz-WIKI
>>>>
>>>> and to send a link to this mailing list. 
>>>>  
>>>>
>>>> This is our "trial balloon" to find out whether our changes and
>>>> improvements
>>>>
>>>>  
>>>>
>>>> are welcome and how we could integrate them during the next months.
>>>>  
>>>>
>>>> I.e. the following extensions may also be interesting for other
>>>> members
>>>> of the community:
>>>>
>>>>  
>>>>
>>>>  * Advanced custom SQL integration
>>>>  * advanced sorting (locale, collation, natural sort)
>>>>  * completely refactored TransactionUtil with documentation and hints
>>>>
>>>>
>>>>  * on-demand "real"-sql-logging for ALL ofbiz statements
>>>> ...
>>>>  
>>>>
>>>> I placed our stuff at
>>>>
>>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>>> and hope one of the "Ofbiz gurus" will have a look at the attached
>>>> stuff to make a statement.
>>>>
>>>>  
>>>>
>>>> Thank you in advance!
>>>>
>>>>  
>>>>
>>>> Best regards
>>>>
>>>>  
>>>>
>>>> Karl Eilebrecht
>>>>
>>>> -- 
>>>> Karl Eilebrecht
>>>> Key-Work Consulting GmbH
>>>>
>>>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>>>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>>>> karl.eilebrecht@key-work.de
>>>>
>>>>
>>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>>
>>>>
>>>
>>>
>>
>>
>>
> 
> 

Re: AW: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Karl,

First, if you can manage to break up your enhancements into cleanly demarcated blocks, please do 
so, and also follow document at 
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices . If not, we can proceed.

I was assuming you couldn't give me a patch created from Jan 07 OFBiz revision (what's the rev 
number?) to your current work. If you can, then just send me that patch, and skip the following. 
But if by any chance the patch isn't valid (ie, you performed the diffs and merges wrongly), we'll 
still have to revert to original plan.

 > As I understand first option is to send you two archives, one with the
 > original distribution we downloaded in January and a second one also
 > including our changes.

Yes. And if you can manage, please take out the 35MB of 3rd-party binaries. Code binaries have no 
business living in SVN, actually. But before you remove those binaries, please create an md5 
manifest of all these binaries. I'll need that manifest.

Once you've taken out the 35MB binaries, the actual OFBiz codes should compress to... about 6MB. 
Neat? :) (I'm contemplating removing Dojo from SVN as well, since the 4MB+ codes can be considered 
"3rd-party binaries".)

So you never did a merge-in of OFBiz updates into your work? You mean you started your work from a 
Jan 07 OFBiz revision?

 > Second option is to download the next release (coming these days?),
 > merge this and send you the pre-merged archive to do a check.

There is no next release, far as I can tell. If you're talking about the release branch, I'd 
suggest you don't hold your breath. You can operate with the trunk as well as you can with the 
"supposedly more stable" release branch. A newly-born release branch is actually as unstable as 
the trunk! Will take some time before the release branch matures to release-standard quality.

You can certainly pull in the latest OFBiz trunk revision (let's call this "Start Revision") and 
perform the merge yourself, and then send me the merged result. Still, let me know the exact 
revision number of this "Start Revision". And please perform this risky wholesale merge on an 
insulated exploratory branch in your repository.

In that case, I will perform a quick compare between your work and the "Start Revision". If by any 
chance you had performed the merge incorrectly, we will still have to revert to the original plan.

 > I've got an account at https://issues.apache.org/jira/browse/OFBIZ
 > Is it correct that I will have to attach a large archive to an issue
 > created in advance by yourself or myself?

No, please don't attach an entire archive of your codes. It's better to attach small deltas.

You are free to create a new Jira issue, perhaps entitled "Karl's Big Enhancements". It really is 
up to the community to discuss it or not.

 > If you're going to create the initial issue (mentioned in your last posting)
 > please send me the issue number. I'll also put a link on that wiki page.

I think it's best that you create the Jira issue. Ultimately, you're the contributor here. You'll 
need to do a "code grant" via Jira when attaching your patch, so that you grant your work to the 
ASF. I can't do it for you.

And lastly, do know that I'm performing this merge for you for free, but on condition that you put 
your contributions under the ASL 2.0. In the worst case, I could be the only SVN that contains 
your enhancements (aside from your own SVN), but at least I'll have them all under ASL 2.0.

Jonathon

Eilebrecht, Karl (Key-Work) wrote:
> Jonathon,
> 
> I'll discuss this with a colleague.
> As I understand first option is to send you 
> two archives, one with the original distribution we
> downloaded in January and a second one also including
> our changes.
> Second option is to download the next release (coming these days?), 
> merge this and send you the pre-merged archive to do a check. 
> 
> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
> Is it correct that I will have to attach a large archive to an issue
> created in advance by yourself or myself?
> 
> If you're going to create the initial issue (mentioned in your last posting)
> please send me the issue number. I'll also put a link on that wiki page.
> 
> Thanks for your support!
> 
> Regards.
> Karl
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Jonathon -- Improov [mailto:jonw@improov.com] 
> Gesendet: Montag, 23. April 2007 13:38
> An: dev@ofbiz.apache.org
> Betreff: Re: AW: Ofbiz Contribution Proposal
> 
> Karl,
> 
> It's a great offer on your part too, to let us have those codes!
> 
> If you've done a merge with OFBiz trunk on 2007-01-05, that means you already know how to keep in 
> step with OFBiz trunk head! You can actually do what I do, on your own.
> 
> That said, if you still need my help, see the following.
> 
> These are what I'll need from you:
> 
> a. Exact OFBiz revision you started off from.
> 
>     (Try to send me a tarball of that revision so I don't have to do a SVN
>     download which can be a real pain thanks to the 35MB of 3rd-party
>     libraries. My own SVN doesn't include those 35MB or 3rd-party binaries; let
>     me know if you want advise on how to cut a lean SVN without binaries.)
> 
> b. Tarball of your latest work you want merged with OFBiz trunk head.
> 
> (Please do an "export"; I don't need the .cvs files.)
> 
> What I will give you is a tarball of this: OFBiz trunk head (I'll state revision for our 
> reference) married with the latest of your work.
> 
> You will have to test this tarball over time, get back to me about problems, and I'll keep sending 
> you fixed tarballs (or deltas, rather). We won't even have to touch the official OFBiz SVN.
> 
> For the initial "review", I will at least make sure it compiles and runs. You will have to test 
> your own functions to see they still work with the latest updates from OFBiz SVN.
> 
> So, here's the summary of the process:
> 
> 1. We merge latest of OFBiz with your stuff.
> 
> 2. Review A: We make sure your stuff still works.
> 
> 3. Review B: We (or community) make sure the general OFBiz stuff still works.
> 
> 4. We submit a patch (diff OFBiz to Your_work) to community.
> 
> And then the ball will be in their (committers') court.
> 
> Generally, you can pretty much stop at step 2 if all you want is the latest of OFBiz working with 
> your stuff. If you had done your customizations in a backward-compatible manner, step 3 won't be 
> very difficult or even necessary at all.
> 
> Jonathon
> 
> Eilebrecht, Karl (Key-Work) wrote:
>> Hi Jonathan, hi Chris,
>>
>> thank you for your feedback (and also thank you for stiring up a hornet's nest ;-) )
>>
>> @Chris: I will try to answer your questions on the wiki page:
>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>> I think this is more comfortable to retrace.
>>
>> @Jonathan: It's a great offer you made to take a look on our code and to
>> evtl. merge it! What's the best way to provide the code to you?
>> I'll have to prepare some things before:
>> - for historical reasons we have a CVS repository and I
>> or one of my colleagues will set up an SVN client. Is it more convenient to
>> you to get an archive for the first review or would you recommend to 
>> pump the sources into a repository? (where?)
>> - I already have added the Apache-Header (ASL) to all of the classes
>> we might contribute.
>> - I'll have to replace all tabs in the sources by 4 spaces.
>>
>> The rest I think should be not too complex, our last framework merge (with trunk) was on 2007-01-05, I don't think there are dramatic low level interface changes since then.
>>
>> We have already switched to Java 6 but all the classes to be contributed
>> are compileable with Java 1.4.
>>
>> Regards.
>> Karl
>>
>> BTW: During the next weeks there may be some "communication delays" because I'll not be in the office all the time. So please don't worry if an email answer needs some days, thanks!
>>
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com] 
>> Gesendet: Samstag, 21. April 2007 08:33
>> An: dev@ofbiz.apache.org
>> Betreff: Re: Ofbiz Contribution Proposal
>>
>> Hi Karl,
>>
>> I had the opportunity today to quickly read over your introductions.
>> And must say it looks very interesting.  Unfortunately, for my being
>> able to add input to the process, the improvements are in areas as an
>> OFBiz user, that I take for granted and don't really get my hands dirty
>> with. 
>>
>> I'll need to read over the transaction part again to ask any
>> intelligent questions, so I'll leave that for later.
>>
>> The custom SQL stuff looked very interesting and probably one of the
>> larger areas of benefit as more and more people are getting to the
>> point of locating bottlenecks in their applications.  I was wondering
>> if there might be some benefit in encapsulating the stored sql
>> statements it in an XML structure to be able to better take advantage
>> of some META data/commenting that you discussed as well as potential of
>> some reusability and structuring of those custom statements.
>>
>> Perhaps, I need to reread the logging discussion again, and ask if this
>> is largely supported among other databases, but can't most of these
>> logging of the sql statements be handled in the database's log, if
>> configured to do so?  I recall a mention that the developer may not
>> have sufficient access to the database server to ascertain the database
>> logs...is this case where the logging proposal would be more
>> beneficial?
>>
>> Thank you and Key-Work very much for bringing these enhancements back
>> to the community!
>>
>> Chris 
>>
>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
>>
>>> Hi,
>>>
>>>  
>>>
>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>
>>>  
>>>
>>> Last year I had mail contact with David.
>>>
>>>  
>>>
>>> He recommended to contribute changes to the Ofbiz Community regularly
>>> whenever possible and useful. 
>>>
>>>  
>>>
>>> It is a long time since this happened, but we finally convinced our
>>> management to try
>>>
>>>  
>>>
>>> to contribute some changes and extensions to the Ofbiz community.
>>>
>>>  
>>>
>>> I read the FAQ and found out that especially complex changes might
>>> take a long time
>>>
>>>  
>>>
>>> and we may need some "community attendance".
>>>
>>>  
>>>
>>> David told me to place our proposal at the Ofbiz-WIKI
>>>
>>> and to send a link to this mailing list.  
>>>
>>>  
>>>
>>> This is our "trial balloon" to find out whether our changes and
>>> improvements
>>>
>>>  
>>>
>>> are welcome and how we could integrate them during the next months. 
>>>
>>>  
>>>
>>> I.e. the following extensions may also be interesting for other
>>> members 
>>>
>>> of the community:
>>>
>>>  
>>>
>>>  * Advanced custom SQL integration 
>>>
>>>  * advanced sorting (locale, collation, natural sort) 
>>>
>>>  * completely refactored TransactionUtil with documentation and hints
>>>
>>>
>>>  * on-demand "real"-sql-logging for ALL ofbiz statements 
>>>
>>> ... 
>>>
>>>  
>>>
>>> I placed our stuff at
>>>
>> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>> and hope one of the "Ofbiz gurus" will have a look at the attached
>>> stuff to make a statement.
>>>
>>>  
>>>
>>> Thank you in advance!
>>>
>>>  
>>>
>>> Best regards
>>>
>>>  
>>>
>>> Karl Eilebrecht
>>>
>>> -- 
>>> Karl Eilebrecht
>>> Key-Work Consulting GmbH
>>>
>>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>>> karl.eilebrecht@key-work.de
>>>
>>>
>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>
>>>
>>
>>
> 
> 
> 

Re: AW: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Karl,

I'm afraid Chris is right about the legal tangle. If I take in your codes, I'll have to perform a 
legal review myself before using it in production. Or I risk being sued and having to pull out 
your codes (plus my codes that are built on top of yours). Tedious and messy at best.

Just because I am able to marry OFBiz and your work (even plus my own) successfully in code, 
doesn't mean I have them reconciled legally.

But to argue from an opposite perspective, one could say it's a similar legal tangle with small 
patches. Small or big, the Licensor will still have to trust that the Contributor is indeed 
submitting his own (not stolen) work. (See http://www.apache.org/licenses/LICENSE-2.0.html).

Jonathon

Chris Howe wrote:
> Hi Karl,
> I suspect simply creating a Jira issue and attaching a patch with the
> ASF license radio button clicked would be the best approach for now.  
> 
> (All) Correct me if I'm wrong, but because of the likely size and or
> complexity of the contribution, I think eventually it will need a "code
> grant" before actually being added to the project.  But the Jira issue
> should allow us to be able to play with the work and get a discussion
> going around it.
> 
> I would like to discourage you and others from sharing patches or
> exports directly that you intend to contribute back to the community
> project as it makes potential intellectual property issues that much
> more difficult to iron out.
> 
> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
> 
>> Jonathon,
>>
>> I'll discuss this with a colleague.
>> As I understand first option is to send you 
>> two archives, one with the original distribution we
>> downloaded in January and a second one also including
>> our changes.
>> Second option is to download the next release (coming these days?), 
>> merge this and send you the pre-merged archive to do a check. 
>>
>> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
>> Is it correct that I will have to attach a large archive to an issue
>> created in advance by yourself or myself?
>>
>> If you're going to create the initial issue (mentioned in your last
>> posting)
>> please send me the issue number. I'll also put a link on that wiki
>> page.
>>
>> Thanks for your support!
>>
>> Regards.
>> Karl
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jonathon -- Improov [mailto:jonw@improov.com] 
>> Gesendet: Montag, 23. April 2007 13:38
>> An: dev@ofbiz.apache.org
>> Betreff: Re: AW: Ofbiz Contribution Proposal
>>
>> Karl,
>>
>> It's a great offer on your part too, to let us have those codes!
>>
>> If you've done a merge with OFBiz trunk on 2007-01-05, that means you
>> already know how to keep in 
>> step with OFBiz trunk head! You can actually do what I do, on your
>> own.
>>
>> That said, if you still need my help, see the following.
>>
>> These are what I'll need from you:
>>
>> a. Exact OFBiz revision you started off from.
>>
>>     (Try to send me a tarball of that revision so I don't have to do
>> a SVN
>>     download which can be a real pain thanks to the 35MB of 3rd-party
>>     libraries. My own SVN doesn't include those 35MB or 3rd-party
>> binaries; let
>>     me know if you want advise on how to cut a lean SVN without
>> binaries.)
>>
>> b. Tarball of your latest work you want merged with OFBiz trunk head.
>>
>> (Please do an "export"; I don't need the .cvs files.)
>>
>> What I will give you is a tarball of this: OFBiz trunk head (I'll
>> state revision for our 
>> reference) married with the latest of your work.
>>
>> You will have to test this tarball over time, get back to me about
>> problems, and I'll keep sending 
>> you fixed tarballs (or deltas, rather). We won't even have to touch
>> the official OFBiz SVN.
>>
>> For the initial "review", I will at least make sure it compiles and
>> runs. You will have to test 
>> your own functions to see they still work with the latest updates
>> from OFBiz SVN.
>>
>> So, here's the summary of the process:
>>
>> 1. We merge latest of OFBiz with your stuff.
>>
>> 2. Review A: We make sure your stuff still works.
>>
>> 3. Review B: We (or community) make sure the general OFBiz stuff
>> still works.
>>
>> 4. We submit a patch (diff OFBiz to Your_work) to community.
>>
>> And then the ball will be in their (committers') court.
>>
>> Generally, you can pretty much stop at step 2 if all you want is the
>> latest of OFBiz working with 
>> your stuff. If you had done your customizations in a
>> backward-compatible manner, step 3 won't be 
>> very difficult or even necessary at all.
>>
>> Jonathon
>>
>> Eilebrecht, Karl (Key-Work) wrote:
>>> Hi Jonathan, hi Chris,
>>>
>>> thank you for your feedback (and also thank you for stiring up a
>> hornet's nest ;-) )
>>> @Chris: I will try to answer your questions on the wiki page:
>>>
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>>> I think this is more comfortable to retrace.
>>>
>>> @Jonathan: It's a great offer you made to take a look on our code
>> and to
>>> evtl. merge it! What's the best way to provide the code to you?
>>> I'll have to prepare some things before:
>>> - for historical reasons we have a CVS repository and I
>>> or one of my colleagues will set up an SVN client. Is it more
>> convenient to
>>> you to get an archive for the first review or would you recommend
>> to 
>>> pump the sources into a repository? (where?)
>>> - I already have added the Apache-Header (ASL) to all of the
>> classes
>>> we might contribute.
>>> - I'll have to replace all tabs in the sources by 4 spaces.
>>>
>>> The rest I think should be not too complex, our last framework
>> merge (with trunk) was on 2007-01-05, I don't think there are
>> dramatic low level interface changes since then.
>>> We have already switched to Java 6 but all the classes to be
>> contributed
>>> are compileable with Java 1.4.
>>>
>>> Regards.
>>> Karl
>>>
>>> BTW: During the next weeks there may be some "communication delays"
>> because I'll not be in the office all the time. So please don't worry
>> if an email answer needs some days, thanks!
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Chris Howe [mailto:cjhowe76013@yahoo.com] 
>>> Gesendet: Samstag, 21. April 2007 08:33
>>> An: dev@ofbiz.apache.org
>>> Betreff: Re: Ofbiz Contribution Proposal
>>>
>>> Hi Karl,
>>>
>>> I had the opportunity today to quickly read over your
>> introductions.
>>> And must say it looks very interesting.  Unfortunately, for my
>> being
>>> able to add input to the process, the improvements are in areas as
>> an
>>> OFBiz user, that I take for granted and don't really get my hands
>> dirty
>>> with. 
>>>
>>> I'll need to read over the transaction part again to ask any
>>> intelligent questions, so I'll leave that for later.
>>>
>>> The custom SQL stuff looked very interesting and probably one of
>> the
>>> larger areas of benefit as more and more people are getting to the
>>> point of locating bottlenecks in their applications.  I was
>> wondering
>>> if there might be some benefit in encapsulating the stored sql
>>> statements it in an XML structure to be able to better take
>> advantage
>>> of some META data/commenting that you discussed as well as
>> potential of
>>> some reusability and structuring of those custom statements.
>>>
>>> Perhaps, I need to reread the logging discussion again, and ask if
>> this
>>> is largely supported among other databases, but can't most of these
>>> logging of the sql statements be handled in the database's log, if
>>> configured to do so?  I recall a mention that the developer may not
>>> have sufficient access to the database server to ascertain the
>> database
>>> logs...is this case where the logging proposal would be more
>>> beneficial?
>>>
>>> Thank you and Key-Work very much for bringing these enhancements
>> back
>>> to the community!
>>>
>>> Chris 
>>>
>>> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>
>> wrote:
>>>> Hi,
>>>>
>>>>  
>>>>
>>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>>
>>>>  
> === message truncated ===
> 
> 

Re: AW: Ofbiz Contribution Proposal

[Chris Howe <cj...@yahoo.com>]

Hi Karl,
I suspect simply creating a Jira issue and attaching a patch with the
ASF license radio button clicked would be the best approach for now.  

(All) Correct me if I'm wrong, but because of the likely size and or
complexity of the contribution, I think eventually it will need a "code
grant" before actually being added to the project.  But the Jira issue
should allow us to be able to play with the work and get a discussion
going around it.

I would like to discourage you and others from sharing patches or
exports directly that you intend to contribute back to the community
project as it makes potential intellectual property issues that much
more difficult to iron out.

--- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:

> Jonathon,
> 
> I'll discuss this with a colleague.
> As I understand first option is to send you 
> two archives, one with the original distribution we
> downloaded in January and a second one also including
> our changes.
> Second option is to download the next release (coming these days?), 
> merge this and send you the pre-merged archive to do a check. 
> 
> I've got an account at https://issues.apache.org/jira/browse/OFBIZ
> Is it correct that I will have to attach a large archive to an issue
> created in advance by yourself or myself?
> 
> If you're going to create the initial issue (mentioned in your last
> posting)
> please send me the issue number. I'll also put a link on that wiki
> page.
> 
> Thanks for your support!
> 
> Regards.
> Karl
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Jonathon -- Improov [mailto:jonw@improov.com] 
> Gesendet: Montag, 23. April 2007 13:38
> An: dev@ofbiz.apache.org
> Betreff: Re: AW: Ofbiz Contribution Proposal
> 
> Karl,
> 
> It's a great offer on your part too, to let us have those codes!
> 
> If you've done a merge with OFBiz trunk on 2007-01-05, that means you
> already know how to keep in 
> step with OFBiz trunk head! You can actually do what I do, on your
> own.
> 
> That said, if you still need my help, see the following.
> 
> These are what I'll need from you:
> 
> a. Exact OFBiz revision you started off from.
> 
>     (Try to send me a tarball of that revision so I don't have to do
> a SVN
>     download which can be a real pain thanks to the 35MB of 3rd-party
>     libraries. My own SVN doesn't include those 35MB or 3rd-party
> binaries; let
>     me know if you want advise on how to cut a lean SVN without
> binaries.)
> 
> b. Tarball of your latest work you want merged with OFBiz trunk head.
> 
> (Please do an "export"; I don't need the .cvs files.)
> 
> What I will give you is a tarball of this: OFBiz trunk head (I'll
> state revision for our 
> reference) married with the latest of your work.
> 
> You will have to test this tarball over time, get back to me about
> problems, and I'll keep sending 
> you fixed tarballs (or deltas, rather). We won't even have to touch
> the official OFBiz SVN.
> 
> For the initial "review", I will at least make sure it compiles and
> runs. You will have to test 
> your own functions to see they still work with the latest updates
> from OFBiz SVN.
> 
> So, here's the summary of the process:
> 
> 1. We merge latest of OFBiz with your stuff.
> 
> 2. Review A: We make sure your stuff still works.
> 
> 3. Review B: We (or community) make sure the general OFBiz stuff
> still works.
> 
> 4. We submit a patch (diff OFBiz to Your_work) to community.
> 
> And then the ball will be in their (committers') court.
> 
> Generally, you can pretty much stop at step 2 if all you want is the
> latest of OFBiz working with 
> your stuff. If you had done your customizations in a
> backward-compatible manner, step 3 won't be 
> very difficult or even necessary at all.
> 
> Jonathon
> 
> Eilebrecht, Karl (Key-Work) wrote:
> > Hi Jonathan, hi Chris,
> > 
> > thank you for your feedback (and also thank you for stiring up a
> hornet's nest ;-) )
> > 
> > @Chris: I will try to answer your questions on the wiki page:
> >
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> > I think this is more comfortable to retrace.
> > 
> > @Jonathan: It's a great offer you made to take a look on our code
> and to
> > evtl. merge it! What's the best way to provide the code to you?
> > I'll have to prepare some things before:
> > - for historical reasons we have a CVS repository and I
> > or one of my colleagues will set up an SVN client. Is it more
> convenient to
> > you to get an archive for the first review or would you recommend
> to 
> > pump the sources into a repository? (where?)
> > - I already have added the Apache-Header (ASL) to all of the
> classes
> > we might contribute.
> > - I'll have to replace all tabs in the sources by 4 spaces.
> > 
> > The rest I think should be not too complex, our last framework
> merge (with trunk) was on 2007-01-05, I don't think there are
> dramatic low level interface changes since then.
> > 
> > We have already switched to Java 6 but all the classes to be
> contributed
> > are compileable with Java 1.4.
> > 
> > Regards.
> > Karl
> > 
> > BTW: During the next weeks there may be some "communication delays"
> because I'll not be in the office all the time. So please don't worry
> if an email answer needs some days, thanks!
> > 
> > 
> > 
> > 
> > 
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Chris Howe [mailto:cjhowe76013@yahoo.com] 
> > Gesendet: Samstag, 21. April 2007 08:33
> > An: dev@ofbiz.apache.org
> > Betreff: Re: Ofbiz Contribution Proposal
> > 
> > Hi Karl,
> > 
> > I had the opportunity today to quickly read over your
> introductions.
> > And must say it looks very interesting.  Unfortunately, for my
> being
> > able to add input to the process, the improvements are in areas as
> an
> > OFBiz user, that I take for granted and don't really get my hands
> dirty
> > with. 
> > 
> > I'll need to read over the transaction part again to ask any
> > intelligent questions, so I'll leave that for later.
> > 
> > The custom SQL stuff looked very interesting and probably one of
> the
> > larger areas of benefit as more and more people are getting to the
> > point of locating bottlenecks in their applications.  I was
> wondering
> > if there might be some benefit in encapsulating the stored sql
> > statements it in an XML structure to be able to better take
> advantage
> > of some META data/commenting that you discussed as well as
> potential of
> > some reusability and structuring of those custom statements.
> > 
> > Perhaps, I need to reread the logging discussion again, and ask if
> this
> > is largely supported among other databases, but can't most of these
> > logging of the sql statements be handled in the database's log, if
> > configured to do so?  I recall a mention that the developer may not
> > have sufficient access to the database server to ascertain the
> database
> > logs...is this case where the logging proposal would be more
> > beneficial?
> > 
> > Thank you and Key-Work very much for bringing these enhancements
> back
> > to the community!
> > 
> > Chris 
> > 
> > --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de>
> wrote:
> > 
> >> Hi,
> >>
> >>  
> >>
> >> we use Ofbiz (mostly the entity engine) for over 2 years now.
> >>
> >>  
> 
=== message truncated ===

AW: Ofbiz Contribution Proposal

["Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>]

Jonathon,

I'll discuss this with a colleague.
As I understand first option is to send you 
two archives, one with the original distribution we
downloaded in January and a second one also including
our changes.
Second option is to download the next release (coming these days?), 
merge this and send you the pre-merged archive to do a check. 

I've got an account at https://issues.apache.org/jira/browse/OFBIZ
Is it correct that I will have to attach a large archive to an issue
created in advance by yourself or myself?

If you're going to create the initial issue (mentioned in your last posting)
please send me the issue number. I'll also put a link on that wiki page.

Thanks for your support!

Regards.
Karl





-----Ursprüngliche Nachricht-----
Von: Jonathon -- Improov [mailto:jonw@improov.com] 
Gesendet: Montag, 23. April 2007 13:38
An: dev@ofbiz.apache.org
Betreff: Re: AW: Ofbiz Contribution Proposal

Karl,

It's a great offer on your part too, to let us have those codes!

If you've done a merge with OFBiz trunk on 2007-01-05, that means you already know how to keep in 
step with OFBiz trunk head! You can actually do what I do, on your own.

That said, if you still need my help, see the following.

These are what I'll need from you:

a. Exact OFBiz revision you started off from.

    (Try to send me a tarball of that revision so I don't have to do a SVN
    download which can be a real pain thanks to the 35MB of 3rd-party
    libraries. My own SVN doesn't include those 35MB or 3rd-party binaries; let
    me know if you want advise on how to cut a lean SVN without binaries.)

b. Tarball of your latest work you want merged with OFBiz trunk head.

(Please do an "export"; I don't need the .cvs files.)

What I will give you is a tarball of this: OFBiz trunk head (I'll state revision for our 
reference) married with the latest of your work.

You will have to test this tarball over time, get back to me about problems, and I'll keep sending 
you fixed tarballs (or deltas, rather). We won't even have to touch the official OFBiz SVN.

For the initial "review", I will at least make sure it compiles and runs. You will have to test 
your own functions to see they still work with the latest updates from OFBiz SVN.

So, here's the summary of the process:

1. We merge latest of OFBiz with your stuff.

2. Review A: We make sure your stuff still works.

3. Review B: We (or community) make sure the general OFBiz stuff still works.

4. We submit a patch (diff OFBiz to Your_work) to community.

And then the ball will be in their (committers') court.

Generally, you can pretty much stop at step 2 if all you want is the latest of OFBiz working with 
your stuff. If you had done your customizations in a backward-compatible manner, step 3 won't be 
very difficult or even necessary at all.

Jonathon

Eilebrecht, Karl (Key-Work) wrote:
> Hi Jonathan, hi Chris,
> 
> thank you for your feedback (and also thank you for stiring up a hornet's nest ;-) )
> 
> @Chris: I will try to answer your questions on the wiki page:
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> I think this is more comfortable to retrace.
> 
> @Jonathan: It's a great offer you made to take a look on our code and to
> evtl. merge it! What's the best way to provide the code to you?
> I'll have to prepare some things before:
> - for historical reasons we have a CVS repository and I
> or one of my colleagues will set up an SVN client. Is it more convenient to
> you to get an archive for the first review or would you recommend to 
> pump the sources into a repository? (where?)
> - I already have added the Apache-Header (ASL) to all of the classes
> we might contribute.
> - I'll have to replace all tabs in the sources by 4 spaces.
> 
> The rest I think should be not too complex, our last framework merge (with trunk) was on 2007-01-05, I don't think there are dramatic low level interface changes since then.
> 
> We have already switched to Java 6 but all the classes to be contributed
> are compileable with Java 1.4.
> 
> Regards.
> Karl
> 
> BTW: During the next weeks there may be some "communication delays" because I'll not be in the office all the time. So please don't worry if an email answer needs some days, thanks!
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Chris Howe [mailto:cjhowe76013@yahoo.com] 
> Gesendet: Samstag, 21. April 2007 08:33
> An: dev@ofbiz.apache.org
> Betreff: Re: Ofbiz Contribution Proposal
> 
> Hi Karl,
> 
> I had the opportunity today to quickly read over your introductions.
> And must say it looks very interesting.  Unfortunately, for my being
> able to add input to the process, the improvements are in areas as an
> OFBiz user, that I take for granted and don't really get my hands dirty
> with. 
> 
> I'll need to read over the transaction part again to ask any
> intelligent questions, so I'll leave that for later.
> 
> The custom SQL stuff looked very interesting and probably one of the
> larger areas of benefit as more and more people are getting to the
> point of locating bottlenecks in their applications.  I was wondering
> if there might be some benefit in encapsulating the stored sql
> statements it in an XML structure to be able to better take advantage
> of some META data/commenting that you discussed as well as potential of
> some reusability and structuring of those custom statements.
> 
> Perhaps, I need to reread the logging discussion again, and ask if this
> is largely supported among other databases, but can't most of these
> logging of the sql statements be handled in the database's log, if
> configured to do so?  I recall a mention that the developer may not
> have sufficient access to the database server to ascertain the database
> logs...is this case where the logging proposal would be more
> beneficial?
> 
> Thank you and Key-Work very much for bringing these enhancements back
> to the community!
> 
> Chris 
> 
> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
> 
>> Hi,
>>
>>  
>>
>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>
>>  
>>
>> Last year I had mail contact with David.
>>
>>  
>>
>> He recommended to contribute changes to the Ofbiz Community regularly
>> whenever possible and useful. 
>>
>>  
>>
>> It is a long time since this happened, but we finally convinced our
>> management to try
>>
>>  
>>
>> to contribute some changes and extensions to the Ofbiz community.
>>
>>  
>>
>> I read the FAQ and found out that especially complex changes might
>> take a long time
>>
>>  
>>
>> and we may need some "community attendance".
>>
>>  
>>
>> David told me to place our proposal at the Ofbiz-WIKI
>>
>> and to send a link to this mailing list.  
>>
>>  
>>
>> This is our "trial balloon" to find out whether our changes and
>> improvements
>>
>>  
>>
>> are welcome and how we could integrate them during the next months. 
>>
>>  
>>
>> I.e. the following extensions may also be interesting for other
>> members 
>>
>> of the community:
>>
>>  
>>
>>  * Advanced custom SQL integration 
>>
>>  * advanced sorting (locale, collation, natural sort) 
>>
>>  * completely refactored TransactionUtil with documentation and hints
>>
>>
>>  * on-demand "real"-sql-logging for ALL ofbiz statements 
>>
>> ... 
>>
>>  
>>
>> I placed our stuff at
>>
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>> and hope one of the "Ofbiz gurus" will have a look at the attached
>> stuff to make a statement.
>>
>>  
>>
>> Thank you in advance!
>>
>>  
>>
>> Best regards
>>
>>  
>>
>> Karl Eilebrecht
>>
>> -- 
>> Karl Eilebrecht
>> Key-Work Consulting GmbH
>>
>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>> karl.eilebrecht@key-work.de
>>
>>
>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>
>>
> 
> 
> 

Re: AW: Ofbiz Contribution Proposal

[Jonathon -- Improov <jo...@improov.com>]

Karl,

It's a great offer on your part too, to let us have those codes!

If you've done a merge with OFBiz trunk on 2007-01-05, that means you already know how to keep in 
step with OFBiz trunk head! You can actually do what I do, on your own.

That said, if you still need my help, see the following.

These are what I'll need from you:

a. Exact OFBiz revision you started off from.

    (Try to send me a tarball of that revision so I don't have to do a SVN
    download which can be a real pain thanks to the 35MB of 3rd-party
    libraries. My own SVN doesn't include those 35MB or 3rd-party binaries; let
    me know if you want advise on how to cut a lean SVN without binaries.)

b. Tarball of your latest work you want merged with OFBiz trunk head.

(Please do an "export"; I don't need the .cvs files.)

What I will give you is a tarball of this: OFBiz trunk head (I'll state revision for our 
reference) married with the latest of your work.

You will have to test this tarball over time, get back to me about problems, and I'll keep sending 
you fixed tarballs (or deltas, rather). We won't even have to touch the official OFBiz SVN.

For the initial "review", I will at least make sure it compiles and runs. You will have to test 
your own functions to see they still work with the latest updates from OFBiz SVN.

So, here's the summary of the process:

1. We merge latest of OFBiz with your stuff.

2. Review A: We make sure your stuff still works.

3. Review B: We (or community) make sure the general OFBiz stuff still works.

4. We submit a patch (diff OFBiz to Your_work) to community.

And then the ball will be in their (committers') court.

Generally, you can pretty much stop at step 2 if all you want is the latest of OFBiz working with 
your stuff. If you had done your customizations in a backward-compatible manner, step 3 won't be 
very difficult or even necessary at all.

Jonathon

Eilebrecht, Karl (Key-Work) wrote:
> Hi Jonathan, hi Chris,
> 
> thank you for your feedback (and also thank you for stiring up a hornet's nest ;-) )
> 
> @Chris: I will try to answer your questions on the wiki page:
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> I think this is more comfortable to retrace.
> 
> @Jonathan: It's a great offer you made to take a look on our code and to
> evtl. merge it! What's the best way to provide the code to you?
> I'll have to prepare some things before:
> - for historical reasons we have a CVS repository and I
> or one of my colleagues will set up an SVN client. Is it more convenient to
> you to get an archive for the first review or would you recommend to 
> pump the sources into a repository? (where?)
> - I already have added the Apache-Header (ASL) to all of the classes
> we might contribute.
> - I'll have to replace all tabs in the sources by 4 spaces.
> 
> The rest I think should be not too complex, our last framework merge (with trunk) was on 2007-01-05, I don't think there are dramatic low level interface changes since then.
> 
> We have already switched to Java 6 but all the classes to be contributed
> are compileable with Java 1.4.
> 
> Regards.
> Karl
> 
> BTW: During the next weeks there may be some "communication delays" because I'll not be in the office all the time. So please don't worry if an email answer needs some days, thanks!
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Chris Howe [mailto:cjhowe76013@yahoo.com] 
> Gesendet: Samstag, 21. April 2007 08:33
> An: dev@ofbiz.apache.org
> Betreff: Re: Ofbiz Contribution Proposal
> 
> Hi Karl,
> 
> I had the opportunity today to quickly read over your introductions.
> And must say it looks very interesting.  Unfortunately, for my being
> able to add input to the process, the improvements are in areas as an
> OFBiz user, that I take for granted and don't really get my hands dirty
> with. 
> 
> I'll need to read over the transaction part again to ask any
> intelligent questions, so I'll leave that for later.
> 
> The custom SQL stuff looked very interesting and probably one of the
> larger areas of benefit as more and more people are getting to the
> point of locating bottlenecks in their applications.  I was wondering
> if there might be some benefit in encapsulating the stored sql
> statements it in an XML structure to be able to better take advantage
> of some META data/commenting that you discussed as well as potential of
> some reusability and structuring of those custom statements.
> 
> Perhaps, I need to reread the logging discussion again, and ask if this
> is largely supported among other databases, but can't most of these
> logging of the sql statements be handled in the database's log, if
> configured to do so?  I recall a mention that the developer may not
> have sufficient access to the database server to ascertain the database
> logs...is this case where the logging proposal would be more
> beneficial?
> 
> Thank you and Key-Work very much for bringing these enhancements back
> to the community!
> 
> Chris 
> 
> --- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:
> 
>> Hi,
>>
>>  
>>
>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>
>>  
>>
>> Last year I had mail contact with David.
>>
>>  
>>
>> He recommended to contribute changes to the Ofbiz Community regularly
>> whenever possible and useful. 
>>
>>  
>>
>> It is a long time since this happened, but we finally convinced our
>> management to try
>>
>>  
>>
>> to contribute some changes and extensions to the Ofbiz community.
>>
>>  
>>
>> I read the FAQ and found out that especially complex changes might
>> take a long time
>>
>>  
>>
>> and we may need some "community attendance".
>>
>>  
>>
>> David told me to place our proposal at the Ofbiz-WIKI
>>
>> and to send a link to this mailing list.  
>>
>>  
>>
>> This is our "trial balloon" to find out whether our changes and
>> improvements
>>
>>  
>>
>> are welcome and how we could integrate them during the next months. 
>>
>>  
>>
>> I.e. the following extensions may also be interesting for other
>> members 
>>
>> of the community:
>>
>>  
>>
>>  * Advanced custom SQL integration 
>>
>>  * advanced sorting (locale, collation, natural sort) 
>>
>>  * completely refactored TransactionUtil with documentation and hints
>>
>>
>>  * on-demand "real"-sql-logging for ALL ofbiz statements 
>>
>> ... 
>>
>>  
>>
>> I placed our stuff at
>>
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
>> and hope one of the "Ofbiz gurus" will have a look at the attached
>> stuff to make a statement.
>>
>>  
>>
>> Thank you in advance!
>>
>>  
>>
>> Best regards
>>
>>  
>>
>> Karl Eilebrecht
>>
>> -- 
>> Karl Eilebrecht
>> Key-Work Consulting GmbH
>>
>> Kriegsstr. 100 - 76133 Karlsruhe - Germany
>> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
>> karl.eilebrecht@key-work.de
>>
>>
>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>
>>
> 
> 
> 

AW: Ofbiz Contribution Proposal

["Eilebrecht, Karl (Key-Work)" <ka...@key-work.de>]

Hi Jonathan, hi Chris,

thank you for your feedback (and also thank you for stiring up a hornet's nest ;-) )

@Chris: I will try to answer your questions on the wiki page:
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
I think this is more comfortable to retrace.

@Jonathan: It's a great offer you made to take a look on our code and to
evtl. merge it! What's the best way to provide the code to you?
I'll have to prepare some things before:
- for historical reasons we have a CVS repository and I
or one of my colleagues will set up an SVN client. Is it more convenient to
you to get an archive for the first review or would you recommend to 
pump the sources into a repository? (where?)
- I already have added the Apache-Header (ASL) to all of the classes
we might contribute.
- I'll have to replace all tabs in the sources by 4 spaces.

The rest I think should be not too complex, our last framework merge (with trunk) was on 2007-01-05, I don't think there are dramatic low level interface changes since then.

We have already switched to Java 6 but all the classes to be contributed
are compileable with Java 1.4.

Regards.
Karl

BTW: During the next weeks there may be some "communication delays" because I'll not be in the office all the time. So please don't worry if an email answer needs some days, thanks!






-----Ursprüngliche Nachricht-----
Von: Chris Howe [mailto:cjhowe76013@yahoo.com] 
Gesendet: Samstag, 21. April 2007 08:33
An: dev@ofbiz.apache.org
Betreff: Re: Ofbiz Contribution Proposal

Hi Karl,

I had the opportunity today to quickly read over your introductions.
And must say it looks very interesting.  Unfortunately, for my being
able to add input to the process, the improvements are in areas as an
OFBiz user, that I take for granted and don't really get my hands dirty
with. 

I'll need to read over the transaction part again to ask any
intelligent questions, so I'll leave that for later.

The custom SQL stuff looked very interesting and probably one of the
larger areas of benefit as more and more people are getting to the
point of locating bottlenecks in their applications.  I was wondering
if there might be some benefit in encapsulating the stored sql
statements it in an XML structure to be able to better take advantage
of some META data/commenting that you discussed as well as potential of
some reusability and structuring of those custom statements.

Perhaps, I need to reread the logging discussion again, and ask if this
is largely supported among other databases, but can't most of these
logging of the sql statements be handled in the database's log, if
configured to do so?  I recall a mention that the developer may not
have sufficient access to the database server to ascertain the database
logs...is this case where the logging proposal would be more
beneficial?

Thank you and Key-Work very much for bringing these enhancements back
to the community!

Chris 

--- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:

> Hi,
> 
>  
> 
> we use Ofbiz (mostly the entity engine) for over 2 years now.
> 
>  
> 
> Last year I had mail contact with David.
> 
>  
> 
> He recommended to contribute changes to the Ofbiz Community regularly
> whenever possible and useful. 
> 
>  
> 
> It is a long time since this happened, but we finally convinced our
> management to try
> 
>  
> 
> to contribute some changes and extensions to the Ofbiz community.
> 
>  
> 
> I read the FAQ and found out that especially complex changes might
> take a long time
> 
>  
> 
> and we may need some "community attendance".
> 
>  
> 
> David told me to place our proposal at the Ofbiz-WIKI
> 
> and to send a link to this mailing list.  
> 
>  
> 
> This is our "trial balloon" to find out whether our changes and
> improvements
> 
>  
> 
> are welcome and how we could integrate them during the next months. 
> 
>  
> 
> I.e. the following extensions may also be interesting for other
> members 
> 
> of the community:
> 
>  
> 
>  * Advanced custom SQL integration 
> 
>  * advanced sorting (locale, collation, natural sort) 
> 
>  * completely refactored TransactionUtil with documentation and hints
> 
> 
>  * on-demand "real"-sql-logging for ALL ofbiz statements 
> 
> ... 
> 
>  
> 
> I placed our stuff at
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> 
> and hope one of the "Ofbiz gurus" will have a look at the attached
> stuff to make a statement.
> 
>  
> 
> Thank you in advance!
> 
>  
> 
> Best regards
> 
>  
> 
> Karl Eilebrecht
> 
> -- 
> Karl Eilebrecht
> Key-Work Consulting GmbH
> 
> Kriegsstr. 100 - 76133 Karlsruhe - Germany
> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
> karl.eilebrecht@key-work.de
> 
> 
> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> Geschäftsführer: Andreas Stappert, Tobin Wotring
> 
> 

Re: Ofbiz Contribution Proposal

[Chris Howe <cj...@yahoo.com>]

Hi Karl,

I had the opportunity today to quickly read over your introductions.
And must say it looks very interesting.  Unfortunately, for my being
able to add input to the process, the improvements are in areas as an
OFBiz user, that I take for granted and don't really get my hands dirty
with. 

I'll need to read over the transaction part again to ask any
intelligent questions, so I'll leave that for later.

The custom SQL stuff looked very interesting and probably one of the
larger areas of benefit as more and more people are getting to the
point of locating bottlenecks in their applications.  I was wondering
if there might be some benefit in encapsulating the stored sql
statements it in an XML structure to be able to better take advantage
of some META data/commenting that you discussed as well as potential of
some reusability and structuring of those custom statements.

Perhaps, I need to reread the logging discussion again, and ask if this
is largely supported among other databases, but can't most of these
logging of the sql statements be handled in the database's log, if
configured to do so?  I recall a mention that the developer may not
have sufficient access to the database server to ascertain the database
logs...is this case where the logging proposal would be more
beneficial?

Thank you and Key-Work very much for bringing these enhancements back
to the community!

Chris 

--- "Eilebrecht, Karl  (Key-Work)" <ka...@key-work.de> wrote:

> Hi,
> 
>  
> 
> we use Ofbiz (mostly the entity engine) for over 2 years now.
> 
>  
> 
> Last year I had mail contact with David.
> 
>  
> 
> He recommended to contribute changes to the Ofbiz Community regularly
> whenever possible and useful. 
> 
>  
> 
> It is a long time since this happened, but we finally convinced our
> management to try
> 
>  
> 
> to contribute some changes and extensions to the Ofbiz community.
> 
>  
> 
> I read the FAQ and found out that especially complex changes might
> take a long time
> 
>  
> 
> and we may need some "community attendance".
> 
>  
> 
> David told me to place our proposal at the Ofbiz-WIKI
> 
> and to send a link to this mailing list.  
> 
>  
> 
> This is our "trial balloon" to find out whether our changes and
> improvements
> 
>  
> 
> are welcome and how we could integrate them during the next months. 
> 
>  
> 
> I.e. the following extensions may also be interesting for other
> members 
> 
> of the community:
> 
>  
> 
>  * Advanced custom SQL integration 
> 
>  * advanced sorting (locale, collation, natural sort) 
> 
>  * completely refactored TransactionUtil with documentation and hints
> 
> 
>  * on-demand "real"-sql-logging for ALL ofbiz statements 
> 
> ... 
> 
>  
> 
> I placed our stuff at
>
http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> 
> and hope one of the "Ofbiz gurus" will have a look at the attached
> stuff to make a statement.
> 
>  
> 
> Thank you in advance!
> 
>  
> 
> Best regards
> 
>  
> 
> Karl Eilebrecht
> 
> -- 
> Karl Eilebrecht
> Key-Work Consulting GmbH
> 
> Kriegsstr. 100 - 76133 Karlsruhe - Germany
> Fon: +49-721-78203-277 - Fax: +49-721-78203-10
> karl.eilebrecht@key-work.de
> 
> 
> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> Geschäftsführer: Andreas Stappert, Tobin Wotring
> 
>