Talk:Software Development Procedure

From ADempiere ERP Wiki

Jump to: navigation, search

Contents

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.

In my limited experience working with OSGI HengSin, i wonder if one simple way can be just a hg clone / then thereafter hg pull into your own PC, synch with your other working branch, get the diff and commit back into your own repository. Maybe a guideline from someone who has a real branch to commit will help. - Redhuan D. Oon 22:49, 10 January 2011 (UTC)

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:

  • Make the SVN-Repo read-only
  • Ask Tony to update the HG-repo one last time
  • Create a clone from the converted HG-repo's "development"-branch (a.k.a trunk) and define that branch as our initial codebase
    • Now or later, create a "stabilization" branch
  • 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
  • IMHO, some parts of the ABP about Trunk strictness is misunderstood. On one hand it sounds strict, but on the other it does not restrict your own branch at all. Hopefully Mercurial usage helps in synching. But the issue i remember last time this was in flames was not about how to synch, but the right to work in trunk or have their work not in branch but directly in the trunk for the more attractive purpose of getting more attention and feedback from the community. This was the argument put forth for the Libero branch. - Redhuan D. Oon 22:43, 10 January 2011 (UTC)

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:

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
Personal tools