Adrian, Cameron,
I agree with Adrian that the "rest of us" should submit patches in a standard format, so that the
"few of them (committers/reviewers)" can efficiently go through them.
But I also agree with Cameron that his process of tidying up his patch, documenting it, etc, took
too much time for no effect.
Without going into arguing about whether Cameron's patch is really "standard digestible format"
for the committers, I'd say in general that this is the way open source projects are. To be fair
to OFBiz, I know many other open source projects that have bug reports (and submitted patches)
sitting untouched for months, even years.
At the end of the day, how fast OFBiz progresses depends on how fast it aligns itself with market
demand, demand in this case meaning user requirements, users like Cameron and Adrian and myself.
For some projects that are blazingly fast in progress, their core team even takes it upon
themselves to rewrite submitted patches that are not readily digestible. A submitted/suggested
patch is still better than a complaint alone.
However, I do admit that we (users) sometimes submit invalid complaints or bug reports or
infeasible feature requests. I guess the key is to politely turn away the "weird" users, and keep
the good ones (those who are great testers, good market feelers, possibly even strong coders
themselves).
So, in conclusion, nobody is wrong here. OFBiz team has to make a choice about prioritizing our
submitted JIRA issues or patches, since resources will always be limited. On the other hand, users
(like Adrian, Cameron, etc) will have to "alter their contribution behavior" accordingly. All we
can hope for is that those of us who were submitting suggestions wrongly will in time learn to do
so correctly; and those who were reviewing suggestions wrongly could possibly learn too.
Whatever our "altered behaviors" are, we face the consequences fairly. If I choose to drop OFBiz
due to such "grunges", I must accept a big loss of a great platform. If OFBiz chooses to "drop"
users like me, OFBiz must rely on the other 399 users to help spur OFBiz growth. (Just a
hypothetical statement for illustration; I'm NOT dropping OFBiz!!)
Like Cameron says, the benefits of OFBiz far outweighs such "grunges". :)
Jonathon
Adrian Crum wrote:
Cameron,
I haven't been following this thread closely, but your last reply caught
my attention - so I'm kind of jumping in at the last moment.
I looked at the Jira issue Jacopo mentioned, and I agree with what was
said in that issue and in Jacopo's reply. If you want to see anything in
Jira included in the main project, then you have to follow certain
standards. The same applies if you just want people to take a look at it
and comment on it.
I would like to evaluate your contribution, but I can't do it in the
form it is in. I need the ability to download a patch and examine what
files the patch affects. Annyone else in the community would evaluate
your contribution in the same way.
Not too long ago I was in the same position you're in. I had submitted
contributions to Jira and they just sat there - for the same reason
yours is. After David and others pointed out to me what was wrong with
them, I took steps to get my contributions to follow OFBiz standards and
then my work started making its way into the project.
-Adrian
Cameron Smith wrote:
Yes, Jacopo. That's the issue I was talking about. With all due
respect, though, I don't think you got the point of my JIRA post.
Perhaps I didn't write it clearly enough.
I uploaded this JIRA issue specifically for it to be committed to the
trunk, after several people on the ML suggested I do so. It would
benefit me as well, as it means less differences from the trunk for
"my company's OFBiz".
I made some specific requests for people more familiar with the
codebase than I to review certain aspects, rather than simply
"committing it and hope for the best", which seems to be the normal
OFBiz approach (yes, I am in the camp that favours branching unless we
have automated regression tests).
Given how heavily OFBiz depends on beanshell, I think you can
understand why I took this aproach. The alternative would be to
commit and then wait for loads of screens to be broken for the next
several weeks.
The most obvious reviewer, David himself, was too busy the last time I
contacted him and I am not going to hassle him about it! He has and
continues to contribute an enormous amount of time, often thanklessly,
to the project.
This was a grungy piece of work to do. I had to do it because
otherwise we couldn't use the UI framework we wanted, and I reckoned
that the many benefits brought by ofbiz outweighed the costs of the
grunge. Once I had achieved my goal, I then spent another several
hours tidying up, testing and writing it up in JIRA.
I would be quite happy if a commiter wrote back and said "we're not
going to use this fix". Fair enough. But just leaving it sitting
there?? To a certain extent this is the norm on any decentralized
project. But projects do differ, and that is why I alter my
contribution behaviour based on the "behaviour" of each project.
anyway, cheers,
cameron
___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less,
sign up for
your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html
