This Wiki is read-only for reference purposes to avoid broken links.

What is

Branch GlobalQSS Adempiere361 is an Adempiere subproject maintained by Carlos Ruiz, sponsored by GlobalQSS company.

Branch is totally open source, open for everybody to contribute, intended to establish proper governance and improve quality assurance procedures.

VISION

Six words can describe our vision on the project -> QUALITY SOFTWARE COMMON EXTENSIBLE PRODUCT CODEBASE

QUALITY SOFTWARE: Because we believe that a piece of software which is vital for enterprises must have basic rules that are respected by maintainers, rules so simple like code must be tested, and rules more complex like backward compatibility, clear migration path, etc.

COMMON: Because we consider silly to have forks per implementor (something usual in Compiere times), all implementors have some common requirements, there is a common kernel of needs that everybody requires, and our goal is to include common needs in a configurable way when the need can vary slightly in different scenarios.

EXTENSIBLE: Not everything needs to be included in the common kernel, there are non-common needs that require to be treated as an extension, and our vision is to evolve the project to a very extensible kernel

PRODUCT CODEBASE: Because we believe that Adempiere must be managed like a common product, not like a project. Product not in the "commercial" sense of the word, but in the management sense, when we have a vision to manage Adempiere as a product then backward compatibility becomes important, maintenance of installed base becomes important, and all the concepts that a Software House consider to have a quality product. Project vision tend to sacrifice those product things in the search for quick results. We prefer slow results with a proper quality.

What we want to achieve

A quality Adempiere product that can be useful for companies just after installed, no need to hire a company to fix the bugs, the downloaded software MUST run smoothly since the beginning

What we want to avoid

People committing incomplete or untested things pushing others to complete/review/fix their underdeveloped code
- Please note this is not going against the principle Release early, release often, we want to encourage people to contribute, but, when you're conscious about the incompleteness of your code, or the lack of enough tests, then please share it in an experimental branch, and allow things to evolve with a proper peer review there. Experimental branches are by definition unstable, you must cope with the possibility of more frequent crashes or even data loss. In this branch the goal is to provide a safer environment for people using this software in production, with specific needs of stability and a safer evolution path.
Companies maintaining their own private version without sharing even the most basic bugs
Companies/people exploiting instability to sell stabilization services (like in Compiere times)

What is included

The subproject is composed by the (actually in svn, soon in mercurial) folders:

Permissions

Write-permissions over the three folders composing the branch are exclusive to branch maintainers, no one else must commit directly on the branch, but anybody can contribute sending patches for peer review and indeed we encourage community to send us patches (in a proper format) to improve the product.

The People

Maintainers

The right to add/drop maintainers is reserved to the main maintainer:

Main maintainer: Carlos Ruiz

At this stage there are no more maintainers defined for the project, and the idea is to keep the number low, we expect most of contributions to arrive via patches instead of direct commits.

There is provision for module maintainers, this is maintainers of a specific functionality, extension, module. These maintainers will have permissions to do direct commit on things related to their scope.

Team

The subproject has a functional/technical team to review, discuss and vote for functional specifications, technical discussions and architectural movements.

The team is composed of:

Followers

Followers are people that have expressed his desire to help in the subproject but - because of any reasons - are not so active as the team:

NOTE: Feel free to add your name here.

How to contribute

There are plenty of ways to contribute, reporting bugs, bringing ideas, suggesting functional specifications,

Reporting bugs

To report bugs please follow the guide How to report a bug

Bringing ideas

To report an idea please use ideatorrent and bring attention to your idea adding a message in the Functional ERP forum linking to your idea

Suggesting functional specifications

To suggest a functional specification please follow the Functional Specification Process

Contributing code for functional specifications

If you have code to contribute, please follow first the Functional Specification Process.

If you want to contribute the code for an already approved Functional Specification, then please open a contribution tracker and upload there your patches, 2pack and migration scripts.

Contributing sponsorship for approved functional specifications or technical/architectural improvements

If you want to contribute with money to develop any approved functional specification or technical/architectural improvement, please contact Carlos Ruiz writing an e-mail to [1]

Policies

Patches policies

Code must be contributed via patches, patches must be complete, include migration scripts for oracle and postgresql databases, or include a 2pack with all the modifications required to dictionary.

If the code is to fix a bug, the bug report must follow the How to report a bug format.

If the code is to implement a functional specification, then FS must follow the Functional Specification Process, and there must be a document explaining the implementation following the format Functional Specification Template

Try to send your patches generated using the latest version of code, maintainers reserve the right to reject to review a patch that doesn't follow the guidelines expressed here.

Contribution policies

There are guidelines to follow when contributing.

First of all, please read and try to apply the ADempiere Best Practices, many of them are suggestions, but is highly encouraged to follow most of them
please read and follow the Release Commit Rules, all of them are mandatory

There are other important behavioral guidelines that you must follow:

When integrating patch from others, please ALWAYS give credit to the original writer of the code. It can be adding comments in the code expressing who wrote it (not recommended), but is compelling to include a comment in the commit giving the credit to the author
Please take note that you're responsible by the code you integrate, if you take code from other people to integrate, you become responsible for the quality of that code, INTEGRATION IS NOT A COPY/PASTE JOB, integration is peer review and quality assurance job. An answer like "I don't know, I just integrated" is not valid when requesting explanation about the contributed code.

Design guidelines

There are design guidelines to follow when contributing:

You must always assume that final user is not aware about what he's doing. For example, deleting in cascade must be considered carefully, implementing delete in cascade can allow a distracted user to inadvertently delete things they don't want to delete. It's always preferrable to compel the user to confirm all the potentially dangerous things before changing data.

Where to download

Subversion repository

You can download the code using any subversion client from these URLs:

Patches strategy for 360

Alternatively you can download version 360 and patches from:

Mercurial repository

Work in progress...

How to set up eclipse

Prerequisites

TBD

Set up project

TBD

How to build

TBD

How to install from scratch

TBD

How to install as patches for 360

TBD

Documentation

Reference Manual

TBD

JavaDoc

TBD

Entity-Relationship Schema and Database Description

TBD

Feature List

TBD

Branch GlobalQSS 361

Contents