All you proposed sound good to me.
Since first discussion about "Lose Weight Program for OFBiz" we (the
company I am working for) have continue to work on addon definition,
rule, goal.
In my current plan, I am 3 week late, but this week (or next one ) I
should create in apache-extra some project :
- addon manager
- addon repository
- ofbiz-extra
- ofbiz-extra-proposed
- ofbiz-extra-dev
for the first addons, I will try to use existing Jira (like theme
proposed, or help system, ...)
The main idea is to be ready (tools, project on apache-extra and time)
to help you to each step.
About release, I agree with Jacopo, OFBiz release should be for ofbiz kernel
and release for ofbiz-extras should exist but it is a other process, not
necessary same people for management for example.
Le 09/07/2012 15:09, Jacopo Cappellato a écrit :
Yes, this could be the easiest way to implement it.
And if and when we will release the "specialpurpose" applications we could simply create a tag (if we do not
plan to backport fixes for "specialpurpose" releases) or we could create a release branch specific for
"specialpurpose" (if we do not want to backport fixes for "specialpurpose" releases).
Jacopo
On Jul 9, 2012, at 2:59 PM, Adrian Crum wrote:
So, we would remove the specialpurpose folder from the release branch? That
sounds fine to me.
-Adrian
On 7/9/2012 1:55 PM, Jacopo Cappellato wrote:
Adrian,
all you proposed sounds good to me, I like it.
What about the idea of not including specialpurpose in the releases? I think it
is important because it simplifies the task of reviewing the code that we
officially publish when we do a release; releasing separately will help to
focus on a smaller amount of code every time we do a release.
Jacopo
On Jul 9, 2012, at 12:50 PM, Adrian Crum wrote:
I like the general direction, but I think the steps are overly complicated. I
would prefer to keep the specialpurpose folder name, and keep its components in
the build scripts and test runs. This is important because higher level
component tests can reveal problems in the core logic (those tests were
invaluable during the Mini-language overhaul).
So, let's move stuff into specialpurpose, then move bits of specialpurpose out
of the project. When the specialpurpose folder is empty, we can remove it.
The eCommerce component could be moved to the applications folder.
I would be interested in spinning off the Asset Maintenance component to a separate
project. Maybe we could use that as a test run of the "extras" concept.
-Adrian
On 7/9/2012 11:21 AM, Jacopo Cappellato wrote:
A few months ago we discussed about moving out of OFBiz some components from framework
and specialpurpose and introduce the concept of "OFBiz Extras" projects,
managed out of the ASF infrastructure.
I still think it is a good way to go, especially because it will help to grow
an ecosystem of projects not necessarily licensed under the same license.
However I understand that this will take time to adjust and a lot of work to setup communities
etc... this is the main reason I have prepared this proposal for an intermediate step: instead of
moving out the components we can move them to the "specialpurpose" folder, rename it into
"extras" and exclude the folder from the ootb build/deployment and from releases.
Some more details:
* the extras folder will not be included in build scripts, test runs,
deployments; in order to build/run/test an extras component, it will have to be
dropped into the hot-deploy folder
* extras components are not deployed on our demo instances, or included in
automated builds; no dependency on them (links, documentation etc...) will
exist in the OFBiz codebase
* some of the components in the extras folder could be experimental; each
component should contain a README file with all the information required to
deploy it successfully
* a separate LICENSE file will be maintained in the extras folder
* extras folder will not be part of the future OFBiz releases; we will instead release
all the extras components in one package as "Apache OFBiz Extras" let's say
every year
* we may consider to move back ecommerce from specialpurpose/extras to
applications, at least the core ecommerce features
Considering that the components are either experimental or very specific, it will be easier to get commit
rights for one or more of the "extras" components; new committers will be formally "OFBiz
committers" (i.e. in theory they will have right to change all code in svn, including ofbiz code) but
they will be asked to limit their field of action to the components they have been voted for; it will be
based on trust rather than commit rights; a formal vote will be still required to authorize the committer to
other components; the fact that a committer will still have the ability to change all code could be an
advantage if we allow them to commit code under the explicit permission of another senior committer on
specific case; for example a senior committer could say "I have committed r123456 and this should be
backported to 12.04 and 11.04 but I don't have time; is there a committer available to help to backport and
test the feature?"
This strategy, to have committers that are asked to not commit out of specific
components, or areas (we could, for example, have a committer allowed to only
work on ui labels), could even be considered for old committers (whose commit
history shows lack of quality)... but this is probably topic for another day.
In short, this approach should help in a few areas: smaller core code base,
greater community of specialized committers, less load on existing committers.
What do you think?
Jacopo
