It might be more helpful for everyone to consider a couple of things:
1. there is no such thing as an OFBiz team that drives the project; OFBiz is a community-driven project and there is no core team that serves the users of the software, only a smaller group that acts as moderators for the community, and anyone with sufficient experience and involvement in the project can become part of that group
2. OFBiz is a very large software project with lots of people involved that covers complicated requirements, and uses some very complex infrastructure; the direct result of this is that it takes a lot of commitment and effort for anyone to participate in the project... I don't believe there is any way around this
In general very few people, even among the OFBiz committers, work on the priorities of other people. We are all here to collaborate and work together, each pushing our own priorities as they arise. The responsibility of the committers is to moderate these efforts to align with a bigger picture so that the project doesn't devolve into total chaos.
As for the BSH contribution in question, that is a tough one because even though there are various committers only 2-3 of the group are really qualified to evaluate and commit this. Hopefully it will get in sooner or later, but until it becomes a priority or of interest to one of the few, keeping in mind it competes with dozens of other outstanding issues and efforts at any given time, that just won't happen.
Hopefully this helps people understand and come to terms with the reality of the project a bit more.
-David On Apr 12, 2007, at 8:31 PM, Jonathon -- Improov wrote:
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
smime.p7s
Description: S/MIME cryptographic signature
