Chris,
The patches/enhancements I bring in are not totally "assessed/reviewed", if that's what you mean
by "review code". I only begin to take apart pinpointed portions of those enhancements when I need
to. I'll try to explain again how I work: I really don't know OFBiz, but I pinpoint exact portions
of what needs to be changed for what effect.
If you know how little time it takes for me to assimilate (like the bad old Borgs, if you watch
Star Trek?) your enhancements into my little playground, you'll likely call me crazy or careless
or both. I don't know how to explain this anymore, except to say that SVN does allow us to be that
reckless, and it does provide facilities for us to minimize risks.
I can probably only give you a counter example.
Have you seen developers stare at a somewhat small portion of code, albeit core codes in
framework, and think and rethink over weeks about immediate directions? Ever seen a group of 5-10
developers discuss that small portion over and over, and go on to project
repercussions/ramifications for each direction that is suggested? It's as if this group of
developers expect ZERO human error to occur. That's not how we should force us humans to work. We
make mistakes, live with that. We just need to devise mechanisms to minimize the
risks/repurcussions of those mistakes. If you play computer games, you'll know a mechanism called
"save games" or something.
We can't have "save points" in real life, can't go back in time. But did you know that version
control systems, with their branch and "timeline" concepts, allow us to border on reckless while
giving us ability to drastically minimize costs of mistakes?
Imagine if you could start multiple branches in your real life. You could try out being a movie
star, a casanova, a do-gooder. Each branch perfectly insulated from the others, no rippling effect
for whatever mistakes you made. Wouldn't you be bolder and more reckless in your moves?
Incidentally, I have a personal motto: Fail fast to learn fast. If you don't try things quickly,
you won't find out quickly that you were wrong. Problem-solving by "process of RAPID elimination"
is very efficient: it's easier to say "what doesn't work" than to say "what does work (in all
universal cases)". You'd have to test a solution in all universal cases for the 2nd type of proof.
I don't know how else to explain these concepts. At the risk of being misconstrued as
"un-helpful", I'm gonna just stop here for such topics, and leave OFBiz to it's way of handling
the "real life" that is the OFBiz SVN. Maybe I could be all wrong.
Jonathon
Chris Howe wrote:
All,
Again, can we please not hijack threads. We have relatively few eyes
that understand the underpinnings of the entity-engine enough to
possibly improve upon it that it would be a shame for that discussion
to get lost in the noise of project administration discussion.
Jonathon,
Hmph, I only have about ten patches in Jira that affect OFBiz code
directly (thus would suffer from difficulty in sharing a progressed
revision) and none of them seem to have comment from you. It's one
thing to leach code; we yield that risk by using the Apache license
specifically and OSS in general, however it seems counter-intuitive to
take the time to review code enough to put it into your private project
but not offer the constructive criticism necessary to get it improved
upon or draw the attention of others to get it into the project.
This seems like a lose-lose-lose approach. You're forced to maintain
obscure code on your own, the author is forced to maintain or abandon
the obscure code and the community doesn't gain the benefit of the code
or the administrative benefit of knowing to ignore the contribution if
it's not a good idea for the project.
--- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
Tim,
I've already taken those "first steps" long ago. Like I said, I don't
know which Jira "feature
requests" are not reviewed; I only know those I have merged into my
own SVN. I really don't have
time to send up itemized or clearly demarcated patches.
Many patches I grabbed from folks (sorry I did it so fast, I don't
even know who), they work. Some
require streamlining mainly to match OFBiz coding standards and such,
but still they do work. By
now, radical patches (like those from Chris Howes?) have gone through
merging, and have even taken
a life (progressed) of their own. That's why I can't tell you "which
Jira issues", because my
"private Jira store", so to speak, has "moved on". If I can do this
aggressively merging without
problems (please use branches for sanity's sake), I am assuming the
community of 400 here can do
the same, if not better. (And I'm guessing a good majority of this
400 might just be doing what I
am doing, and OFBiz is none the better for it.)
For now, let's just all do what we're good at, and keep at it. Maybe
some day, I can submit a
gigantic patch and it will somehow translate into a bigger better
OFBiz. For now, I can't help but
leech off of OFBiz, every single update, but still can't feed the
whole sum back to OFBiz. Tough
on my conscience, but something I'll have to live with.
By the way, I have no idea what some folks here are intending to
achieve with some off-tangent
remarks. If it's "status quo" they want (in relation to me and "my"
patches, ie), they've got it.
If you can understand what I'm doing in my own computers (with OFBiz
and radical patches), that's
good and you may do the same good(?) thing in time. If not, I may
change my bad(?) tactics over
time. Either way, let's just get back to what we're good at.
Jonathon
Tim Ruppert wrote:
Jonathon - as has always been the case - the role of reviewing
"complex"
patches does not fall strictly on the committers - it falls on the
entire community. The committers then have the role of putting the
code
into the trunk.
If you are so concerned that valid works are not being put back
into the
trunk aggressively enough (which I think that everyone who spends
time
over here would agree), could you try the proactive approach of
looking
at more patches and letting the community know which ones you think
are
tested well enough and offer enough value to go back into the
trunk?
That would be a GREAT first step and a very nice change of pace
from the
aggressive tone you seem to think is appropriate.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
David,
"We" do not now, nor have we ever, turned away a contribution
because it
was complex.
Very well, I'll just use the word "you" then. I take it that you
do
not turn away contributions because they were complex.
The question from me would be whether you do or do not turn away,
knowingly or not, contributions that are valid but too complex for
review. It's not rhetorical, but you're free to do your own
sanity/verification checks on that supposed phenomenon and deem it
rhetorical or invalid.
Could you do us all a big favor Jonathon? Your comments seem to
be
fairly consistent along these lines. I think what would be
helpful to
you, and to anyone reading and agreeing with your comments, is
to step
back and try to explain why things are the way they are. Feel
free to
share that with the group for a sanity check if you'd like.
I'm not so sure of the "why" of things, but am only more certain
of
the "what" of things. Things are the way they are, no matter how
we
interpret the "why".
So, for now, I continue to merge in (to my own SVN) several
contributions that are deemed too difficult to review/merge by the
committers. I continue to keep such enhancements in step with
updates
from OFBiz trunk. And I continue in my failure(?) to feed such
"compatibilized/merged" enhancements back to OFBiz trunk even
though
they really are the same license.
And the phenomenon of several of us (incompatible contributors?)
holding on to our own enhancements will continue. Some of us may
not
know how to keep in step with OFBiz trunk updates; others may.
Those
of us who can keep in step will continue to benefit from OFBiz
progress, but be unable to feed the benefit back to OFBiz. There
will
still be enhancements out there that are kept away/apart from
OFBiz.
That's the way of things? Or maybe not?
I stand corrected. I think I am "helping" OFBiz in the wrong way.
I'll
stop that. :) Thanks for reminding me.
I was waiting to dump the loads of my enhancements into your
trunk,
but I think I should take a sanity check for now. Anyway, there
needs
to be at least one stabilizing branch (save point, so to speak)
before
we can go full steam with the trunk. And there's still no such
branch yet.
Jonathon
David E. Jones wrote:
On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote:
We shouldn't turn away complex contributions anymore.
"We" do not now, nor have we ever, turned away a contribution
because
it was complex.
I myself have loads of enhancements (mostly to widget module)
that I
feel uneasy about releasing to the community, simply because of
this
odd use of trunk: it's used like a slow-moving release branch
that
is unable to handle introductions of radical enhancements.
Yet, this somewhat slow-moving trunk isn't still enough and
focused
enough on achieving release-quality stability. It's the worst of
both worlds: it's not rapid enough to allow for radical
progress,
and not calm and focused-on-cleaning-up enough to produce a
stable
release for non-OFBiz developers.
Could you do us all a big favor Jonathon? Your comments seem to
be
fairly consistent along these lines. I think what would be
helpful to
you, and to anyone reading and agreeing with your comments, is to
step back and try to explain why things are the way they are.
Feel
free to share that with the group for a sanity check if you'd
like.
-David
