QA branch

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

At December 2008 the three top committers of adempiere started a quality assurance branch, initiative heavily discussed in forums

Committers

Repository

The repository is accesible here:

http://adempiere.svn.sourceforge.net/viewvc/adempiere/branches/qa/

It was created with revision 7834

Rules

Initial rules for committing within this repository discussed internally by the committers team:

Golden rules

  • Committer must be careful about what is committing - s/he needs to look for collaterals and TRY THE BEST to avoid breaking working functionalities, and document code properly to ease peer review
  • Bug fix and new functionality must have a valid use case and encourage to have unit testing written as well. The use case details should be capture in the corresponding tracker for future reference and peer review.
  • For framework and architecture changes - this is an area where use case and unit testing is not always applicable, hence such changes must be discussed first in a committee meeting and agreed by the majority.
  • Committer must be responsible of his/her commits. If something is broken due to a commit, s/he's the first person responsible to review and fix, obviously teamwork and help is encouraged but the responsibility is upon the person who did the commit

Other rules

  • Committer must show permanent activity
  • committer must review at least 1 contributed tracker every 2 weeks - s/he must review contributed patches in sourceforge trackers and give an answer to contributor.
    • Answer to contributor must precise one of these cases:
      • commit (in this case the commit comment must show the patch contributor - something like "Thanks to [contributor] for this patch" and point to the tracker.
      • Committer can change the contributed code to make it look better or to fix things (but is preferred to contact author for fixing)
      • reject - in this case there must announce in tracker the reason of rejection
      • advice for review - in this case committer must express in tracker what else needs to be reviewed by contributor in order to reach qa branch
  • committers must meet at least every two weeks to discuss technical issues, revoking commit permissions, and propose and vote for new members
  • if a committer can't attend the meeting s/he must announce with at least 2 days of anticipation
  • For the current strategy and architecture, initial optimum number of committers is 7, committers must review the strategy at next meeting when the number of committers reach this number

Proposal for new committers

  • committers can propose new committer and ask for votation, the most important thing is that proposed committer must have contributed properly things in patches and shown care about reviewing collaterals (not breaking other things) and responsibility on his/her commits.
  • any committer can propose a new committter, in this case suggested process is:
    • ask privately to proposed committer if s/he agreed to be voted on commit rights - and if voted positively if s/he agrees to follow the rules and best practices
    • if the proposed committer agrees to be voted, then at next meeting committers must vote
    • simple majority of (counting all committers) will let the new committer in, so this implies quorum is needed to vote new committers
    • if the committer is voted positively then it's announced in forums
    • if the committer is voted negatively then a private note will be sent to the proposed committer explaining and advising what must be improved in order to consider again the voting in future

Lose of commit rights

  • 14 days of inactivity (no commit nor review of trackers)
  • Not attending or participating in two consecutive meetings.
  • Breaking something (compilation, working functionality) without swift response to fix it quickly.

In any of these cases the rest of committers must consider voting to revoke the commit rights at next committer meeting.

  • Corollary: Committer can ask for a grace period when going on vacations, or when s/he is immersed on a specific project for some time.