Jacques,
You lost me. I don't see where you are (or were ever) rude.
> a. You have your own branch(es) of OFBiz
Yes, I have multiple branches sometimes, which will stabilize and collapse into a few (possibly 2
or 3) branches, and then eventually come down to trunk.
Usually, when I see a huge patch(es) I might like, I'll see many branches
popping up.
> b. Not using our standard strategy (moving with the community,
> not alone) you "losed" the control about the changes you made
> respectively to the OFBiz trunk
Hmm. That didn't happen.
The trick is to keep a record of exactly where you branched off, to know how and which
files/folders to do a diff. Of course, you'll need to know which direction to do the diff-patch.
> c. This is not a problem for you (your branch is a fork but good
> for you)
If my branch isn't kept in step with OFBiz trunk, that's not ok for me. The OFBiz trunk is
constantly getting updates and bugfixes. Like I said, the "loss of control" didn't happen. I am
still in step with OFBiz trunk. Only issue I have is that the OFBiz trunk can't keep in step with
my own updates, which is fine by me if I really don't mind kicking back and relaxing after
finishing my own work.
> d. You don't have time to extract your changes atomically but
> with a huge patch (unusable by commiters)
You're right on this count. Due to the way I perform wholesale aggressive merges (to bring in big
enhancements), my commits are not small. They are quite mostly large and wide in scope. I perform
such wholesale merges, then somehow systematically pick off all incompatibilities.
Hence, I can only feed large patches to the community, not atomic ones like "Added feature A" or
"Fixed bug B".
> 3. So your only solution to have your changes in the trunk is for us to
> open a branch for you
No, the solution is for myself to give you a patch that will bring 2 things together: the latest
of OFBiz and the latest of my work. I can tell you that I've tested this patch, but it's really up
to the community to trust me.
On your part, the solution would be to just dump my patch into your trunk. Or if you want to have
a cautious look-see first, you could open a new branch just to test out my patch. This
"exploratory/probationary" branch will be very short-lived, possibly 2-3 updates in the timeline.
After the few updates, you can decide:
a. My patch is playing well with the latest of OFBiz, and you merge it into
trunk.
OR
b. My patch still has too many incompatibilities with OFBiz, and you discard
it.
As you can see, the bulk of the work is on my part, in "bringing the latest of OFBiz and my work
together". The fact that I already have the latest of OFBiz playing with my enhancements is
already more than half the work done.
Most folks I come across don't know how to do that part. I was suggesting that someone among us,
someone comfortable with version control adventures, perform that merge for those who can't.
I'm gonna assume you understand the concepts I tried to describe above. It's
dinner time now.
Ultimately, the concepts involve "maximizing concurrency". It won't be good if I find myself
limiting my rate/size of progress just so I don't "lose control" or lose sight of OFBiz trunk. I
just moved ahead at full speed, all the while being confident that OFBiz trunk will always be
mergeable into my SVN. The question is whether the OFBiz SVN is similarly confident about merging
our mad-cap-paced work into OFBiz trunk.
Jonathon
Jacques Le Roux wrote:
Jonathon,
I don't want to be agressive or let you thing that I like to make
"off-tangent" remarks. Here is what I think (I can't tell that facts):
1. I'm sure you might be able to be a great help for the community.
2. I better understand now why you'd like to have an "open" branch,
correct me if I'm wrong
a. You have your own branch(es) of OFBiz
b. Not using our standard strategy (moving with the community, not
alone) you "losed" the control about the changes you made respectively
to the OFBiz trunk
c. This is not a problem for you (your branch is a fork but good for
you)
d. You don't have time to extract your changes atomically but with a
huge patch (unusable by commiters)
3. So your only solution to have your changes in the trunk is for us to
open a branch for you
Okay I'm a bit rude but you forced me and that's really what I think.
Of course I'm open to discussion, you may also pass by my comments.
Sorry and good luck
Jacques
----- Message d'origine -----
De : "Jonathon -- Improov" <[EMAIL PROTECTED]>
À : <[email protected]>
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
