Please Scott,
Inline...
From: "Scott Gray" <[email protected]>
I disagree, there always have been and always will be bugs in OFBiz,
there is no escaping this fact. The only reason there are more bugs
now than there were 3 years ago is because there is more community
activity. Fixing the bugs in jira will not prevent new bugs from
replacing them (and some of the replacements will be the same bugs we
just fixed).
Don't misundersand me. I'm not worried about new bugs. I totally understand
that this is intrinsic nature of software.
My point is only for us to give more love to these 109 issues waiting attention
in Jira, nothing else...
IMO the best thing we can do for the stability of the project is to
create tests every time we create or modify a service, be it during a
bug fix or while implementing new functionality. Doing so locks in
the desired behavior and prevents anyone from unknowingly changing
that behavior.
Yes, I plenty agree
Even without intervention, bugs naturally get fixed over time as
people come to require the functionality being blocked by the bug, the
key is to do everything we can to reduce the number of new bugs being
created.
I totally agree, I can agree more I should say. i think I should have used "Opened
important Jira issues" as subject :/
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
Thi is all great,
Put please ladies/gents don't get out of subject.
I still think the 1st step is to fix the bugs we know exist, are
documented in Jira and even ready to be fixed with patches for some.
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
From: "Anil Patel" <[email protected]>
We do see some great Ideas around what is needed. There was lot of
conversation on this topic in ApacheCon 2008 and then in 2009
(based on messages on list).
You will be surprised there is lot done. We have seen lot of
activity in documenting business processes and end user
documentation.
More recently David proposed a simple system derived from Ofbiz
that will address needs of small business.
We have lot more Ofbiz technical contributors then Business process
knowledge contributors. It will be really nice if people in this
part of community will step up. It will be nice if business users
or power business users who are technical developers as well
started to take part of requirement documents and add to UBPL or
EZBIZ effort.
If users can document their business processes needs, give some
wireframe help then technical developers will be able to help map
them to OOTB features (Gap Analysis).
Unless we get real business requirements documents coming from user
community there is no way for us to fulfill them.
I hope you understand I am not asking anybody to break NDA or
whatever.
Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
Hi devs,
Here my opinion about the subject.
To make things clear, it makes about 3-4 month I am working with
OFBiz, using it to implement a project.
I thing one way to have more people involved in the project is to
lower the "difficulty level" required to understand OFBiz.
And for this there are several possbilities, and I will focus on
two :
- modularize the project
- more functional documentation inside the source files
Modularize the project
I've seen this subject has already been discussed and I think it can
profit to the project in several points :
- more modules means less code in each module, which means modules
are
eaiser to understand, which means more developer may be
interesting to
participate to its development, test, ... There is at least one
obvious module which could be very interesting to externalize, it's
the entity engine. I don't know so much OFBiz architecture but I
think
it should be possible to externalize this module and a lot of
projects
totally different of OFBiz could be interesting in it, and so
potentially a lot more developers to maintain and enhance it.
- on another side, more modules would also make it easier to
distribute the issues, each developer specialized on a specific
module. Maybe it's already the case...
More functional documentation inside the source files
Here my feeling is that with OFBiz, you really requires both
technical
and functional knowledge to understand how the project work. Some
part
like the entity engine are purely technical, but the order module
for
example is really functional, I mean, you need to know a lot about
how
ordering works in a company to be able to use the module and even
more
to custommize or propose enhancements to it. So, with more
documentation in the source files, like the XML entity files, and
then
in the source code for example explaining what a method concretly
does
may help a lot to understand OFBiz. It seems the link David sent
about
UBML is about his.
Here is my feeling about OFBiz as a fresh developers. I try to
participate to the project at least by providing bug reports, I
still
feel for away from providing patches ! :-)
Hope this will help you, devs, the project is already great, let's
make it more accessible !
Cimballi
