Talk:Software Development Procedure

From ADempiere
Revision as of 05:36, 23 December 2010 by Tobi (Talk) (Stabilization)

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

Switching to HG

tobi42 17:12, 21 December 2010 (UTC)

Introduction to HG

Change of terminology

If we switch to mercurial, the concept is unaffected, there are just some minor differences:

  • Instead of developers creating a branch, they clone the repository. That means, they create a local copy of the repo to work with.
    • Only PMC is required to have write-access to the mercurial-repo.
  • Instead of "trunk", we speak of the Default-Branch

Stabilization

  • Open question for what is currently called "stabilization-branch"
    • With HG, "stabilization" can still be a branch, similar to svn
      • Difference between hg and svn: In SVN, a branch is just a copy that by convention lives under "branches". In HG, it is explicitly created by the hg branch command.
      • On cloning, a developer can create a clone that contains both branches or only a single branch
    • With HG, "stabilization" can be another HG-repository that is initially cloned from "Default" and then sychronized.
    • My opinion: currently I'm in favor of having a stabilization branch, because that way we have only one repo.
      • I see no need to give contributors write access to the stabilization branch, so "Default" and "Stabilisation" could as well be inside the same branch
      • Developers submit their contributions in one of the ways that are described by Carlos here: Branch_GlobalQSS_361#Sending_your_changes_for_peer_review (Tobi 12:36, 23 December 2010 (UTC) ...or directly from the HG-website: http://mercurial.selenic.com/wiki/CommunicatingChanges)
      • Two branches within one repo are roughly half the size of two repos (because they are very similar and thus there is a big duplication)
      • One repo with branches can still be "split" into multiple repos (one per branch) if and when we see that it is the better solution

Synchronizing with ADempiere-OSGI

AFAIK, to synchronizing our HG repository with OSGI (http://kenai.com/projects/hengsin/pages/Home) now or later on, we need to use the existing adempiere-conversion created by Tony Snook. The reason is that Low created Adempiere-OSGI as a clone of that conversion. On top, Tony put a lot of effort into converting our somehow "mangled" repo.

Sugestion for next steps

I suggest to start the new process at the same time that we switch to HG.
The actual conversion to HG could be like this:

  • Ask Tony to update the HG-repo one last time
  • Create a clone from the converted HG-repos "development"-branch (a.k.a trunk) and define that branch as our initial codebase
    • Now or later, create a "stabilization" branch
  • Make the SVN-Repo read-only
  • Give write-access on the HG-repo only to the (technical?) PMC-Team members
  • Voila, that's it

open questions by nwessel

  • do we need to revise the best practices
    • tobi42 08:06, 18 November 2010 (UTC) Here is my opinion
      1. I don't think that the best practices should be written in stone (im am bit sceptical about the "100% compliance" thing, too). It should be up to the PMC teams to interpret and revise them as neccessary.
      2. Therefore I don't think that the ABP need a resivion before this whole thing can start. They are already pretty good to help both the developers in writing good code and the PMC team to do a good review.
  • provide templates and samples for wiki pages

open questions by tobi42

  • I think we should include the Release Commit Rules in the concept. The technical team should only commit stuff to the stabilization-branch, if it meets those rules. This implies that work from a developer branch is only merged into stabilization branch, if those rules are met. WDYT?
    • Nwessel 12:15, 18 November 2010 (UTC) I think the technical team can make usage of that rules and apply them to themselfes.

different diagram by kthiemann

  • I tried to create a more simple diagram to make the process easier to understand:
Sdp easy.png

Here is the list of people

working on the concept and agreeing with it:

  • Teo Sarca
  • Joel Stangeland
  • Victor Perez
  • Werner Scharinger
  • Thomas Kreser
  • Mario Calderon
  • Susanne Calderon
  • Kai Schaeffer
  • Karsten Thiemann
  • Mark Ostermann
  • Norbert Wessel
  • Tobias Schöneberg
  • Dirk Niemeyer
  • Dominik Zajac
  • Ramiro Vergara
  • Christina Ghita