Difference between revisions of "Talk:Software Development Procedure"
From ADempiere
This Wiki is read-only for reference purposes to avoid broken links.
(→Sugestion for next steps) |
(→Sugestion for next steps) |
||
Line 31: | Line 31: | ||
I suggest to start the new process at the same time that we switch to HG.<br> | I suggest to start the new process at the same time that we switch to HG.<br> | ||
The actual conversion to HG could be like this: | 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 | *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 | *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 | **Now or later, create a "stabilization" branch | ||
− | |||
*Give write-access on the HG-repo only to the (technical?) PMC-Team members | *Give write-access on the HG-repo only to the (technical?) PMC-Team members | ||
*Voila, that's it | *Voila, that's it |
Revision as of 09:03, 10 January 2011
Contents
Switching to HG
tobi42 17:12, 21 December 2010 (UTC)
Introduction to HG
- A good tutorial on HG: http://hginit.com/
- If new to HG, I recommend reading it first
- Practical and ADempiere related info is here: Mercurial Test Environment
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
- With HG, "stabilization" can still be a branch, similar to svn
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:
- 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
- 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.
- 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.
- tobi42 08:06, 18 November 2010 (UTC) Here is my opinion
- 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:
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