Re: AW: Ofbiz Contribution Proposal

[David E. Jones]

-David


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

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.

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

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

take care of the formatting issues. If no one from the community picks --- "Eilebrecht, Karl (Key-Work)" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Gesendet: Dienstag, 24. April 2007 05:00
An: dev@ofbiz.apache.org
Betreff: Re: AW: Ofbiz Contribution Proposal

Karl,

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

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

Jonathon

Jonathon -- Improov wrote:

Karl,

First, if you can manage to break up your enhancements into cleanly

demarcated blocks, please do so, and also follow document at

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

. If not, we can proceed.

I was assuming you couldn't give me a patch created from Jan 07

OFBiz

revision (what's the rev number?) to your current work. If you can,

then

just send me that patch, and skip the following. But if by any

chance

the patch isn't valid (ie, you performed the diffs and merges

wrongly),

we'll still have to revert to original plan.

As I understand first option is to send you two archives, one

with the

original distribution we downloaded in January and a second one

also

including our changes.

Yes. And if you can manage, please take out the 35MB of 3rd-party
binaries. Code binaries have no business living in SVN, actually.

But

before you remove those binaries, please create an md5 manifest of

all

these binaries. I'll need that manifest.

Once you've taken out the 35MB binaries, the actual OFBiz codes

should

compress to... about 6MB. Neat? :) (I'm contemplating removing Dojo

from

SVN as well, since the 4MB+ codes can be considered "3rd-party

binaries".)

So you never did a merge-in of OFBiz updates into your work? You

mean

you started your work from a Jan 07 OFBiz revision?

Second option is to download the next release (coming these

days?),

merge this and send you the pre-merged archive to do a check.

There is no next release, far as I can tell. If you're talking

about the

release branch, I'd suggest you don't hold your breath. You can

operate

with the trunk as well as you can with the "supposedly more stable"

release branch. A newly-born release branch is actually as unstable

as

the trunk! Will take some time before the release branch matures to

release-standard quality.

You can certainly pull in the latest OFBiz trunk revision (let's

call

this "Start Revision") and perform the merge yourself, and then

send me

the merged result. Still, let me know the exact revision number of

this

"Start Revision". And please perform this risky wholesale merge on

an

insulated exploratory branch in your repository.

In that case, I will perform a quick compare between your work and

the

"Start Revision". If by any chance you had performed the merge
incorrectly, we will still have to revert to the original plan.

I've got an account at

https://issues.apache.org/jira/browse/OFBIZ

Is it correct that I will have to attach a large archive to an

issue

created in advance by yourself or myself?

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

better to

attach small deltas.

You are free to create a new Jira issue, perhaps entitled "Karl's

Big

Enhancements". It really is up to the community to discuss it or

not.

If you're going to create the initial issue (mentioned in your

last

posting)

please send me the issue number. I'll also put a link on that

wiki page.

I think it's best that you create the Jira issue. Ultimately,

you're the

contributor here. You'll need to do a "code grant" via Jira when
attaching your patch, so that you grant your work to the ASF. I

can't do

it for you.

And lastly, do know that I'm performing this merge for you for

free, but

on condition that you put your contributions under the ASL 2.0. In

the

worst case, I could be the only SVN that contains your enhancements

(aside from your own SVN), but at least I'll have them all under

ASL 2.0.

Jonathon

Eilebrecht, Karl (Key-Work) wrote:

Jonathon,

I'll discuss this with a colleague.
As I understand first option is to send you two archives, one with

the

original distribution we
downloaded in January and a second one also including
our changes.
Second option is to download the next release (coming these

days?),

merge this and send you the pre-merged archive to do a check.
I've got an account at https://issues.apache.org/jira/browse/OFBIZ
Is it correct that I will have to attach a large archive to an

issue

created in advance by yourself or myself?

If you're going to create the initial issue (mentioned in your

last

posting)
please send me the issue number. I'll also put a link on that wiki

page.

Thanks for your support!

Regards.
Karl





-----Ursprüngliche Nachricht-----

=== message truncated ===

smime.p7s
Description: S/MIME cryptographic signature