Revision as of 12:41, 8 October 2010

STATUS: This concept is under work.

This is a suggestion to replace the PMC Head Concept (http://www.adempiere.com/index.php/PMC_Head_Concept).

Why is this concept so big?

The reason is that this concept defines the procedures in order to fillfil the following goals:

• we want to produce high quality ERP software
• we want to have regular releases
• we want to be able to plan new features
• we want an all time stable trunk
• we want to have several features under development at the same time
• we want documentation for new features
• we want teams to be responsible not single persons
• we want a lean project layout

You see, there are a lot of goals that need some structure around it to make the real.

Suggestion for SVN/ Mercurial Structure

Hint to the used names:

• "release" is just a name. SVN standards would call this main line of development "trunk". It should be considered seriously if we should call this "trunk", so that new developers to ADempiere encounter default SVN behavior. This main line of development is called release/ trunk in further concept.

Idea

• Release/ trunk is the main line of Development
• Every 4 months a stabilization branch is created from release/ trunk. It will be nice to already have a Roadmap for the different stabilzation cycles, but it is not a must (new functionalities, changes can be announced by Developers in advance and are the put into the roadmap for stabilzation cycle). The Idea behind this is taken from Scrum. Scrum works with Sprints (fix starting date, fix ending date) and already has predefined userstories before starting the sprint. The stabilzation cycle has a fix starting date and a fix ending date too, but the functionalities must not (but can) be predefined in advance.
  • Developers/ Implementors have 3 months for integrating new functionalities, changes and Bugfixing and Integration testing. The new functionalities are implemented in seperate development branches and merged back to stabilization branch. The maintainer of the development branch has to do his own "public relation" for his development branch, in order to attract more developers for his implementation. He has to prepare the integration carefully together with PMC technical (to be founded) and functional group. Before integrating new/ changed Funtionality in "stabilization" the Developers/ Implementors have to apply for approval by PMC Technical/ Functional Group.
  • After 3 months the stabilization branch is frozen for new features. In this time only further Bugfixing and User Acceptance Tests (UAT) are allowed.
  • After 4 months this stabilzation branch is reintegrated into main line of development and a release is done (svn tag).
  • The next stabilization branch cycle starts. The old branch is deleted. The new one is again created from main line of development (release/ trunk).
• If a developer does not manage to integrate his new/ changed functionalities in the 3 months of integration in a decent manner (that means that he has not achieved approval from PMC Technical/ Functional Group) he is not allowed to integrate into "stabilization". But this is not fatal because the next stabilization cylcle starts one month later. The developer can prepare better and try applying for approval and integration again. Further suggestion: In case the approval is not given to Developer/ Implementor this information is sent per private eMail and not pushed to public. Another large benefit: This process is not a "revert" anymore. It is "not getting an approval". This is a different quality, which could makle this process much easier and less heated in future.

Responsibility: Release Manager

• release/ trunk (in the picture names as "release") is the main line of development in ADempiere svn. It is the root and the only place from where "ADempiere releases" are taken from via tagging.
• "stabilization" branch is opened from release/ trunk every 4 months. The stabilization branch allows new feature integrations and integration testing in the first 3 months. In the last month of "stabilization" branch lifetime, no more features are allowed, only bugfixing/ stabilization work (feature frozen zone). The beginning and end of each "stabilization" cycle is predefined before the cyle starts and afterwards never changed, no matter why. Each "stabilization" branch must end up with a release of "release" after reintegration.
• Hotfixes are allowed in "release", but Release Manager must explicitly permit. The Bug tracker of the Hotfix can only be closed when this Hotfix is fixed in release/ trunk and "stabilization" branch.
• Normal Bugfixes and small Feature Development can/ shall be done in stabilization branch. The changes/ fixes must fulfill requirements/ rules defined by PMC Groups (everybody is invited to participate in these Groups). If requirements are not fulfilled Release Manager can easily decide to revert or demand the developer to fulfill the requirements/ rules quickly.
• Release Manager decides who has the permission to commit to release/ trunk and "stabilization" branch.

Responsibility: Developers

• Every Developer can open an own experimental or feature development branch. The branch can be taken from release/ trunk or "stabilization". The developer who opened the branch is the maintainer of the branch.
• In such branches the complex/ bigger feature development shall take place. Development of new functionality happens only in development branches. The Maintainer shall do the "public relations" for his own branch when he would like to see others helping in his development. Further on he shall discuss the planned Feature Implementations in Forum and open a Feature Request tracker.
• The Maintainer can plan the reintegration/ merge of the features of his branch into "stabilization" branch and inform PMC Head/ PMC Technical/ Functional Groups. This shall be done as early as possible, so that PMC Head/ PMC can oversee the complexity of new Implementations and can give early consultancy about when to integrate. The process of Integration in stabilization branch shall be done working closely together with PMC Head/ PMC Technical/ Functional Groups to avoid reverts/ rejections. Rejections are only temporal. The Maintainer can try to fix the cause of revert quickly or wait for the next "stabilization" branch to integrate his Implementations.
• The Maintainer is responsible to keep his branch up-to-date doing syncing with release/ trunk and/ or "stabilization". Therfor he must merge hotfixes from release/ trunk to his branch.
• The Maintainer decides who has the permission to commit into his branch.
• The Maintainer can provide his own rules for his branch.
• "Dead" or "unmaintained" experimental/ feature development Branches shall be avoided.
• ANY code that is committed to any official branch (including trunk) should respect a set of rules:
  • 100% compliance with Adempiere Best Practices (ABP)
  • code is formated using the official formatting definition (need to be defined and agreed on, but in meantime you can take this as an example)
  • respect Subversion Best Practices (see [1])
• Any data model change should be announced, discussed and voted (example: the placed were we store some well known informations like contact phone changed)
• Master Data Models (organizations, bpartners, contacts, warehouses etc) should be consistent and is not allowed to have different ways of defining the relations between this entities (examples: storing the organization details like addresses, phones, faxes in Organization Info tab or in the linked business partner)
• in case of complex functionalities, ADempiere Generic Workflows should be defined in order to guide the user how to setup the functionality and which is the designed the business process (example: take a look at Manufacturing Management Setup workflow from your ADempiere main menu)
• After approval from PMC Groups (functional, technical, other) code is integrated/ merged to "stabilization" and Integration testing ist done. The maintainer is repsonsible to provide immediate effort if the integration harms the "stabilization" branch.

Responsibility: PMC Technical Group

Any code structural change (e.g. file/ directory rename/ move/ delete) should be announced and approved by PMC Technical Group before applying it. The PMC Technical Group approves/ rejects the integration of new/ changed developments into "stabilization" too. The Developer applies for approval at PMC Technical Group.

• The PMC Technical Group checks if
  • is code documented
  • backward compatibility is achieved
  • migration scripts complete
  • technical documentation sufficient
  • backward comparability analysis
  • migration scripts are provided (when needed)
• The PMC Technical Group approves or rejects an Integration into stabilization branch from a technical perspective.

Responsibility: PMC Functional Group

Any functional change from ADempiere default should be announced and approved by PMC Functional Team before applying it (examples: documents behavior changed from standard, processes behavior changed from default, main menu items moved from their default location, fields of a standard window were reorganized etc.). The PMC Technical Group approves/ rejects the integration of new/ changed developments into "stabilization" too. The Developer applies for approval at PMC Functional Group.

• The PMC Functional group checks checks if
  • requirement makes sense
  • requirement is solved
  • test cases are complete and meet the requirement
  • user documentation sufficient
  • the ADempiere Wiki-Page describing this functionality contains
    • requirement specification
    • test cases
    • test documentation (how tested which test cases with which results)
    • user documentation
• The PMC Functional Group has got the final decision on which feature is accepted. The PMC Functional Group approves or rejects an Integration into stabilization branch from a functional perspective.

Responsibility: Other PMC Groups

There are already other PMC Groups that could be integrated into this Integration Process where it makes sense. For example Usability, Security Group.

Reverting policy

• PMC technical group has the responsibility to revert code that is not compliance with our rules set (technical, functional).
• The revert should be motivated precisely and without any doubt.
• Any other person outside of the technical group (including the functional group) are not allowed to revert, but are advised to call for a revert where they specify the concrete reasons.
• In case there is a contribution that based on strong reasons is not well done, but is respecting the "SVN Procedure", we can call for a community process to modify the "SVN Procedure" and to enforce this rule from now on.

See Also

• Community Governance‎