On 14/12/2015 4:40 PM, Jacques Le Roux wrote:
Hi Ron,
It's interesting, and I agree with you we must organise the project
and ourselves "more". But it's too early for me at the moment :/
Sorry but I prefer to keep focused on simple tasks (baby steps) for
now, this one is about specialpurpose components :)
It is a start and is raising the discussion about structure even if it
is not as sweeping as I would like.
The discussion itself is valuable in bringing some hidden agendas and
undocumented usage and dreams to the fore.
Note that another baby step we have already decided on is to group the
applications data model in one component.
This should hopefully clarify things at the applications level. I
think most dependencies are due to the data model, but I'm not quite
sure about that.
Anything that decouples the various parts is a good step and even if
some problems are found that can not be solved immediately at least they
will have been identified.
Jacques
PS: BTW I just found this article interesting
http://breakingsmart.com/season-1/rough-consensus-and-maximal-interestingness
. Seems that there are a bunch of others as interesting there.
It would be much easier to follow some of the idea expressed here about
agility, freedom and rough consensus if the risks were minimized by
limiting the scope of the impact of the decisions.
Ron
Le 14/12/2015 16:47, Ron Wheeler a écrit :
It seems that this discussion is just dancing around the core problem
with the current structure of OFBiz.
There seems to be a natural set of almost separate projects that are
lumped together into a rather tangled object.
This discussion is nibbling around the edge of the problem rather
than addressing the problem straight up.
To get to the next level of product maturity, we need to find a way
to break the product into manageable pieces with well defined rules
about how it gets extended and how "new" features get integrated.
The framework should be the first to get untangled since that is
supposed to be a separate product.
This is in progress but it not yet clear what the relationship will
be between the new framework and the old one or even OFBiz.
At some point, the leaders of this project are going to have to
decide what is the core ERP application. This means separating:
- core functionality
- core seed data
- seed Data for particular industries or
- demos
- optional application modules
Then there needs to be rules about how new things get added.
Breaking up the people who can commit to each area will add a bit of
discipline to the process.
At the moment any committer can change every level of the structure
to accomplish their goals.
This is very efficient for the person wanting to add something but
creates havoc for the project as a whole.
Getting to a point where releases of individual components can be
made without having to release everything at once will have a lot of
benefits and make it easier to maintain an OFBiz installation.
If you can upgrade the framework without updating the ERP, framework
improvements can be made more rapidly.
If the core ERP can be upgraded without having to worry about every
"special purpose" component ever created, it will get a lot easier to
get releases out.
This means that there will have to be rules and real APIs that you
can not violate.
It will also mean that people wanting to change things that require
changes to multiple levels will have to actually discuss their
proposal and convince the framework team or ERP team to add the
required functionality and test it to make sure that it does not
break the API.
This will also increase the potential for community involvement.
Currently, it is too risky to add committers who only want to work on
one module or even a demo since there is no way to stop them breaking
lots of things accidentally.
Ron
On 14/12/2015 1:01 AM, Jacques Le Roux wrote:
Le 08/12/2015 20:59, Nicolas Malin a écrit :
Le 19/11/2015 11:45, Jacques Le Roux a écrit :
Could we list, apart the well known Birt issue, special
components which
are overriding main applications?
Directly by memory, the scrum components has defined new seca on
cust
request to send email that break the standard customer request
system
An other where I failed, used service findProductsById instead of
findProductById, the first from hhfacilty and the second from
catalog. And
want you start your hot-deploy component without specialpurpose
... paff !
:)
Thanks for these points Nicolas, I agree with Pierre suggestion.
For instance does really the hhfacilty findProductById service
needs to be named the same than in product? Etc.
Of course I'm also for this, but the problem isn't on the capacity
to open a jira issue.
Nicolas
OK, I had an idea. Why not commenting out the specialpurpose
components by default, but uncomment those which have proved to "not
be a problem"?
"Not be a problem" means here which are not overriding applications
component. So we could create a "Comment out specialpurpose
components by default" Jira
with possible subtasks for litigious cases (when we find an issue
after uncommenting out)
I suggest though that we don't do that on trunk (which would still
contains all components active) but on the next frozen release. We
could even do it on R14.12 if we have a consensus.
To start, I'd at least uncomment out:
example
exampleext
pos
ecommerce(? if not OK then we create the main Jira and a subtask for
it)
Adds your please...
Opinions?
Jacques
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
