OFBiz › OFBiz - Dev

Ofbiz Contribution Proposal

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

41 messages Options

123

Eilebrecht, Karl (Key-Work)

AW: Ofbiz Contribution Proposal

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:[hidden email]]
Gesendet: Samstag, 21. April 2007 08:33
An: [hidden email]
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)" <[hidden email]> 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
> [hidden email]
>
>
> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> Geschäftsführer: Andreas Stappert, Tobin Wotring
>
>

Jacques Le Roux

Re: Ofbiz Contribution Proposal

Administrator

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)" <[hidden email]>

> 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:[hidden email]]
> Gesendet: Samstag, 21. April 2007 08:33
> An: [hidden email]
> 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)" <[hidden email]>
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
> > [hidden email]
> >
> >
> > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> > Geschäftsführer: Andreas Stappert, Tobin Wotring
> >
> >
>

Jacques Le Roux

Re: Ofbiz Contribution Proposal

Administrator

Karl,

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

Thanks to share !

Jacques

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

> an email answer needs some days, thanks!
> >
> >
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Chris Howe [mailto:[hidden email]]
> > Gesendet: Samstag, 21. April 2007 08:33
> > An: [hidden email]
> > 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

> > 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)" <[hidden email]>
> 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
> > > [hidden email]
> > >
> > >
> > > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> > > Geschäftsführer: Andreas Stappert, Tobin Wotring
> > >
> > >
> >

jonwimp

Re: AW: Ofbiz Contribution Proposal

In reply to this post by Eilebrecht, Karl (Key-Work)

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:[hidden email]]
> Gesendet: Samstag, 21. April 2007 08:33
> An: [hidden email]
> 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)" <[hidden email]> 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
>> [hidden email]
>>
>>
>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>
>>
>
>
>

jonwimp

Re: Ofbiz Contribution Proposal

In reply to this post by Jacques Le Roux

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)" <[hidden email]>
>
>> 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:[hidden email]]
>> Gesendet: Samstag, 21. April 2007 08:33
>> An: [hidden email]
>> 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)" <[hidden email]>
> 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
>>> [hidden email]
>>>
>>>
>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>
>>>
>
>

Eilebrecht, Karl (Key-Work)

AW: Ofbiz Contribution Proposal

In reply to this post by jonwimp

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:[hidden email]]
Gesendet: Montag, 23. April 2007 13:38
An: [hidden email]
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:

Jacques Le Roux

Re: Ofbiz Contribution Proposal

Administrator

Karl, Jonathon,

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

Jacques

De : "Eilebrecht, Karl (Key-Work)" <[hidden email]>

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:[hidden email]]
> Gesendet: Montag, 23. April 2007 13:38
> An: [hidden email]
> 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:[hidden email]]
> > Gesendet: Samstag, 21. April 2007 08:33
> > An: [hidden email]
> > 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)" <[hidden email]>
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
> >> [hidden email]
> >>
> >>
> >> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
> >> Geschäftsführer: Andreas Stappert, Tobin Wotring
> >>
> >>
> >
> >
> >
>

cjhowe

Re: AW: Ofbiz Contribution Proposal

In reply to this post by Eilebrecht, Karl (Key-Work)

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)" <[hidden email]> wrote:

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:[hidden email]]
> > Gesendet: Samstag, 21. April 2007 08:33
> > An: [hidden email]
> > 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)" <[hidden email]>
> wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> we use Ofbiz (mostly the entity engine) for over 2 years now.
> >>
> >>
>

=== message truncated ===

David E Jones

Re: AW: Ofbiz Contribution Proposal

In reply to this post by Eilebrecht, Karl (Key-Work)

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:[hidden email]]
> Gesendet: Montag, 23. April 2007 13:38
> An: [hidden email]
> 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:[hidden email]]
>> Gesendet: Samstag, 21. April 2007 08:33
>> An: [hidden email]
>> 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)" <[hidden email]>
>> 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
>>> [hidden email]
>>>
>>>
>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>
>>>
>>
>>
>>
>

smime.p7s (3K) Download Attachment

jonwimp

Re: AW: Ofbiz Contribution Proposal

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:[hidden email]]
>> Gesendet: Montag, 23. April 2007 13:38
>> An: [hidden email]
>> 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:[hidden email]]
>>> Gesendet: Samstag, 21. April 2007 08:33
>>> An: [hidden email]
>>> 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)" <[hidden email]> 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
>>>> [hidden email]
>>>>
>>>>
>>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>>
>>>>
>>>
>>>
>>>
>>
>

jonwimp

Re: AW: Ofbiz Contribution Proposal

In reply to this post by cjhowe

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)" <[hidden email]> 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:[hidden email]]
>> Gesendet: Montag, 23. April 2007 13:38
>> An: [hidden email]
>> 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:[hidden email]]
>>> Gesendet: Samstag, 21. April 2007 08:33
>>> An: [hidden email]
>>> 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)" <[hidden email]>
>> wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> we use Ofbiz (mostly the entity engine) for over 2 years now.
>>>>
>>>>
> === message truncated ===
>
>

jonwimp

Re: AW: Ofbiz Contribution Proposal

In reply to this post by Eilebrecht, Karl (Key-Work)

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:[hidden email]]
> Gesendet: Montag, 23. April 2007 13:38
> An: [hidden email]
> 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:[hidden email]]
>> Gesendet: Samstag, 21. April 2007 08:33
>> An: [hidden email]
>> 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)" <[hidden email]> 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
>>> [hidden email]
>>>
>>>
>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>
>>>
>>
>>
>
>
>

jonwimp

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:[hidden email]] Gesendet: Montag,
>> 23. April 2007 13:38
>> An: [hidden email]
>> 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:[hidden email]] Gesendet: Samstag, 21.
>>> April 2007 08:33
>>> An: [hidden email]
>>> 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)" <[hidden email]> 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
>>>> [hidden email]
>>>>
>>>>
>>>> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
>>>> Geschäftsführer: Andreas Stappert, Tobin Wotring
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

Eilebrecht, Karl (Key-Work)

AW: Ofbiz Contribution Proposal

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:[hidden email]]
Gesendet: Dienstag, 24. April 2007 05:00
An: [hidden email]
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:

Jacques Le Roux

Re: Post Branch Enhancements

Administrator

In reply to this post by jonwimp

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" <[hidden email]>
> > À : <[hidden email]>
> > 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" <[hidden email]>
> >>> À : <[hidden email]>
> >>> 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

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

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

cjhowe

Re: AW: Ofbiz Contribution Proposal

In reply to this post by Eilebrecht, Karl (Key-Work)

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)" <[hidden email]> 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:[hidden email]]
> Gesendet: Dienstag, 24. April 2007 05:00
> An: [hidden email]
> 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 ===

David E Jones

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)" <[hidden email]>
> 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:[hidden email]]
>> Gesendet: Dienstag, 24. April 2007 05:00
>> An: [hidden email]
>> 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 ===
>

smime.p7s (3K) Download Attachment

jonwimp

Re: Post Branch Enhancements

In reply to this post by Jacques Le Roux

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" <[hidden email]>
>>> À : <[hidden email]>
>>> 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" <[hidden email]>
>>>>> À : <[hidden email]>
>>>>> 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
>>>
>
>

jonwimp

Re: Post Branch Enhancements

In reply to this post by Jacques Le Roux

Eilebrecht, Karl (Key-Work)

AW: Ofbiz Contribution Proposal

In reply to this post by David E Jones

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:[hidden email]]
Gesendet: Dienstag, 24. April 2007 09:35
An: [hidden email]
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:

--
Karl Eilebrecht
Key-Work Consulting GmbH

Kriegsstr. 100 - 76133 Karlsruhe - Germany
Fon: +49-721-78203-277 - Fax: +49-721-78203-10
[hidden email]

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

123