Branch GlobalQSS 361
Contents
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.
Transition Version to iDempiere
IMPORTANT NOTICE: This branch has been defined as the transition branch to the iDempiere=OSGi+ADempiere project, guaranteeing the most possible smooth transition (DB upgrade will be as always just applying migration scripts). All the bugs (more than 200) and new functionalities fixed on this branch are already included (and constantly added also) into iDempiere.
Branch GlobalQSS 361 released FINAL VERSION - transition to iDempiere project. Since final version no new functionalities will be added to this branch, just bug fixes and periodic patches (as it's tagged LTS).
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
(This is based on actual situations responsible for certain instability in our ADempiere main version. Please discuss further in Talk:Branch_GlobalQSS_361).
- Committing into main production trunk, without a truthful declaration as to its fitness for production usage. A misleading declaration that a contribution is production ready when it is not has led to a lot of loss of business for both the creator and resellers as well as end-users.
- Please note this is not going against the principle of Release early, update often. You are encouraged to release as early as possible but it must be accompanied by a simple README that includes details on what it is and at what stage you are in your development and vitally about what it breaks in design or code.
- Many projects reject any form of contribution that does not provide such sufficient information. And such contributors are banned for knowingly submitting wrongful information in order to protect their own business' interest instead of the project's.
- Companies maintaining their own private version without sharing even the most basic bugs that they have discovered in the course of community progress.
- Companies/people exploiting instability to sell stabilization services (like during Compiere times)
NOTE that all the above is not aimed to be discouraging. But instead they aim at making the whole project survive against competition. A project that is truthful and ethically conducted by its top contributors will ensure maximum market confidence. Sharing a secret behind the code is not giving your business away. Instead "give away your knowledge and earn the right to charge a premium for implementation" is a Second Law of Sales Process Design.
What is included
The subproject is housed within the folder:
Permissions
You don't have and you don't need permissions to commit on this branch, simply you're free and strongly encouraged to fork it and contribute from your fork.
This is the main concept of a [Distributed_revision_control DVCS], and circles of trust concept.
Maintainer
- Main maintainer: Carlos Ruiz
The workflow to evolve on this branch (as well as iDempiere) is intended to be based on the scalable circles of trust approach that Linus Torvalds uses for his linux tree.
Credit Attribution
It is free to take and copy from here.
You must follow the important GPL practice of properly crediting the author, credit stealers have been and will be exposed publicly (screaming loudly 61 times if necessary) until the credits are properly attributed.
Credit attribution is a serious matter, the most important maybe on the open source environment.
On the opposite side, if you copy code from another branch/project/forum-page/whatever and plan to contribute it here you must expose clearly the source (apart from credit attribution, that helps us to verify any potential IP issue).
The People
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:
Meetings
We conduct weekly meetings to discuss issues on this branch and iDempiere project on the FREE / OPEN / PUBLIC IRC channel.
No need to register, or ask for permissions, you just can simply attend.
Date: wednesday 13 to 15 GMT Venue: Freenode IRC #idempiere channel http://webchat.freenode.net/?channels=idempiere
Full logs of the meetings are being published at this link.
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.
The official site to report bugs or suggest new features for this branch or iDempiere is http://jira.idempiere.com
Bringing ideas
To report an idea please use the legendary Red1 forums
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 an iDempiere JIRA ticket 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 or fix about the contributed code.
- You are responsible for the things you commit, when requested for an improvement or a fix an answer like "Feel free to fix it" is not valid (of course you can answer like that, we cannot stop you, but you're damaging the trust we can put on you).
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. In general terms, cascade delete (automatic deletion of child records) must be done just for automatically created records (like translation, accounting, tree)
Where to download
Mercurial repository
HTTPS access
Setting a local clone
To make modifications to this branch the recommended way is to create a local clone of the repository, this can be achieved executing:
- hg clone https://bitbucket.org/CarlosRuiz_globalqss/adempiere361
- hg update globalqss_adempiere361
After you clone the remote sourceforge server, you can clone locally, i.e:
- hg clone adempiere361 mylocalclone
- hg update globalqss_adempiere361
Then please feel free to make changes in your local copy (mylocalclone in the example) and test them.
Committing your changes
Commit in mercurial is different to commit in subversion. Executing "hg commit" just apply the changes to your local clone.
Please choose a proper commit message that summarizes properly the change, and please fill the user information with your sourceforge user, or your e-mail.
Sending your changes for peer review
After you test your changes, let me repeat, after you test your changes and you consider they are complete and ready for production you can share your changes for peer review.
- NOTE: You could agree in an experimental way to share incomplete changes, that is ok for example within a team working on a feature, or agreeing to cross-test, but that is not ok to send your changes for consideration to production.
There are several ways to send your changes for peer review (reference http://mercurial.selenic.com/wiki/CommunicatingChanges):
Create a patch (recommended)
You can create a patch of the committed changes and send the patch to committers via e-mail, or upload to a sourceforge tracker.
- "hg outgoing" let you review the unsent changes and take note of the revision
- "hg export <revision>" > patch.diff" creates a patch.diff file with the changes from revision
You can fork on bitbucket
You can fork adempiere361 within bitbucket very easily, just follow the fork link or follow this link.
After forked in bitbucket you can then use the "pull request" mechanism to contribute back.
(User:Tbayen wrote a documentation about [having your own repository])
Publish in a public repository so I can pull changes from your repository
You can create a clone (fork) in a repository different than bitbucket, and then let maintainers know the revision to check and pull to get the corresponding changes.
Send a bundle
This is similar to create a patch, but a bundle can even contain a whole repository - check hg documentation about bundles
Subversion repository
No longer maintained
How to set up eclipse
Eclipse
Although the project can be compiled and modified using other IDEs (like netbeans) it's recommended to use eclipse.
Please download and install the corresponding version for your operating system and processor from the URL:
It's recommended to download the version named "Eclipse IDE for Java EE Developers" in case you want to debug directly the zkwebui server. "Eclipse IDE for Java Developers" could be enough for people using just swing or planning remote debug.
Mercurial for Eclipse
It is recommended to install the mercurial client for eclipse available here:
Easier way to install is within eclipse:
- Help -> Install New Software ->
- fill "Work with:" -> http://www.javaforge.com/project/HGE
- push the Add button and give a proper name to save the site
- Enable the checkbox to install "Mercurial Eclipse" and push Next and then follow normal eclipse instructions to install software
Is it possible that you need to install mercurial (hg) for your operating system also.
- i.e. in ubuntu is just a matter of "sudo apt-get install mercurial"
Features and Bug Fixes Done
- Too many to document here - you must follow the history of the project to find them.
