Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Gyrex/Contributor Guide/Committer Resources"

m (Workspace Setup)
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page lists useful tips and articles for developers interested in working with/at the Gyrex code base.
+
This article lists useful tips and articles for developers interested in working with/at the Gyrex code base.
  
 +
== Policies & Guidelines ==
  
== Source Control ==
+
=== API ===
 +
The Eclipse Gyrex Project follows the Eclipse Project API guidelines. Please look at [[API Central]] and read the resources carefully. In case of any questions please don't hesitate to ask on [https://dev.eclipse.org/mailman/listinfo/gyrex-dev gyrex-dev@eclipse.org mailing list].
  
Our regular (primary) SCM is CVS.  
+
=== Ramp Down Plan ===
 +
Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects. For milestones, the component lead (or delegate) is enough to review and approve a bug.  
  
=== Anonymous CVS Checkout ===
+
'''For any M6 build, we plan to be API complete''', so there will not be any more breaking API changes or unsolicited API change requests accepted.
  
cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/technology co org.eclipse.gyrex
+
'''After RC1 is produced''', the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:
 +
* A regression
 +
* A P1 or P2 bug, one that is blocking or critical, and some cases of major severities.  
 +
* Documentation and PII files are exceptions to the normal PMC required review, since there is little chance of that breaking anything, though it is still expected to be complete by M6, and remaining work to be only documentation fixes (that is, no refactoring of plugins, build changes, etc, without PMC review and approval).  
 +
* In addition to a bug meeting the above priority/severity conditions, there should be a simple, safe, well understood fix that is well isolated from effecting other components, that doesn't affect API or adopters, that has been well reviewed and well tested.  
 +
* As each Release Candidate passes, the criteria for weighing the benefit-to-risk ratio criteria gets higher and higher, and as such requires a larger number of project members to review.
 +
** After RC1: Another committer from the project must review and vote + using Bugzilla (see below).
 +
** After RC2: Another committer from the project and a project lead must review and vote +1 after reviewing the bug for appropriateness and risk.
  
=== Comitter CVS Checkout ===
+
==== Bugzilla Usage for RC Fixes ====
 +
Committers can signify their approval for submitting fixes as required after RC1 by simply indicating +1 in a comment.
  
  export CVS_RSH=/bin/ssh
+
Bugzilla has a flag feature that is to be used for obtaining PMC approval. Enter the email address of the PMC member you are requesting approval from and submit. The PMC member is notified via email and will change the flag from '?' to '+' or '-' as appropriate.
  cvs -d :ext:your_committer_id@dev.eclipse.org:/cvsroot/technology co org.eclipse.gyrex
+
  
=== Git Mirror ===
+
==== Backporting fixes for service releases ====
  
There is a public Git Mirror maintained by the Eclipse Webmaster.
+
* Bugfixes should be backported to the maintenance branch only if they match the criteria above.
 +
* A review is required if bug fixes should be backported.
 +
* A patch must be attached to every bug which is backported.
 +
* If a bug ''has been'' backported for a service release, a tag of the form "srX_Y_Z" must be added to the status whiteboard field in bugzilla, where X_Y_Z is the service release number without dots (e.g. "sr0_10_1" for Gyrex 0.10.1).
 +
* To request backporting for a service release, a tag of the form "srX_Y_Z?" can be used.
  
git://dev.eclipse.org/org.eclipse.gyrex/org.eclipse.gyrex.git
+
==== See Also ====
 +
* [[Simultaneous_Release]]
 +
* [[Indigo]]
  
=== Git Experiment ===
 
  
Gyrex participated in the Eclipse.org Git experiment. This provides Git repositories for Gyrex committers. However, CVS still is the primary SCM and therefore changes has to be committed to both. They way this works requires some overhead for committers.
 
  
1. Create a clean Git repository containing all the CVS stuff. This might take a while.
+
[[Category:Gyrex]]
 
+
cd <your_gyrex_development_folder>
+
mkdir gyrex-cvsimport.git
+
cd gyrex-cvsimport.git
+
(export CVS_RSH=/bin/ssh)
+
git cvsimport -d :ext:your_committer_id@dev.eclipse.org:/cvsroot/technology org.eclipse.gyrex
+
 
+
2. Create a clone of that repository to work with (we'll call it "working copy").
+
 
+
cd <your_gyrex_development_folder>
+
git clone -l gyrex-cvsimport.git gyrex-wc.git
+
 
+
3. Import that clone into your Eclipse workspace and start editing. You may use EGit to work with the repository.
+
 
+
4. From time to time you need to sync with changes in CVS.
+
 
+
First import the new CVS stuff into your "clean" CVS Git repository
+
 
+
cd <your_gyrex_development_folder>
+
cd gyrex-cvsimport.git
+
git cvsimport -p x -v -d :ext:your_committer_id@dev.eclipse.org:/cvsroot/technology org.eclipse.gyrex
+
 
+
Next, pull the changes into your Git "working copy".
+
 
+
cd <your_gyrex_development_folder>
+
cd gyrex-wc.git
+
git pull
+
 
+
5. Once you have modifications ready to commit, you need to use git cvsexportcommit to "export" the changes into a clean CVS working copy.
+
 
+
First, create the CVS working copy
+
 
+
cd <your_gyrex_development_folder>
+
mkdir gyrex-cvsexport
+
cd gyrex-cvsexport
+
export CVS_RSH=/bin/ssh
+
cvs -d :ext:your_committer_id@dev.eclipse.org:/cvsroot/technology co org.eclipse.gyrex
+
 
+
Next, select the commits from your Git working copy which should be committed to CVS.
+
 
+
cd <your_gyrex_development_folder>
+
cd gyrex-cvsexport
+
export GIT_DIR=<your_gyrex_development_folder>/gyrex-wc.git/.git/
+
git log
+
 
+
Now "export" the commits into the CVS working copy.
+
 
+
git-cvsexportcommit <commit_id>
+
unset GIT_DIR
+
 
+
Last (but not least) commit the changes to CVS.
+
 
+
(Modeled after http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html)
+

Latest revision as of 05:42, 25 February 2015

This article lists useful tips and articles for developers interested in working with/at the Gyrex code base.

Policies & Guidelines

API

The Eclipse Gyrex Project follows the Eclipse Project API guidelines. Please look at API Central and read the resources carefully. In case of any questions please don't hesitate to ask on gyrex-dev@eclipse.org mailing list.

Ramp Down Plan

Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects. For milestones, the component lead (or delegate) is enough to review and approve a bug.

For any M6 build, we plan to be API complete, so there will not be any more breaking API changes or unsolicited API change requests accepted.

After RC1 is produced, the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:

  • A regression
  • A P1 or P2 bug, one that is blocking or critical, and some cases of major severities.
  • Documentation and PII files are exceptions to the normal PMC required review, since there is little chance of that breaking anything, though it is still expected to be complete by M6, and remaining work to be only documentation fixes (that is, no refactoring of plugins, build changes, etc, without PMC review and approval).
  • In addition to a bug meeting the above priority/severity conditions, there should be a simple, safe, well understood fix that is well isolated from effecting other components, that doesn't affect API or adopters, that has been well reviewed and well tested.
  • As each Release Candidate passes, the criteria for weighing the benefit-to-risk ratio criteria gets higher and higher, and as such requires a larger number of project members to review.
    • After RC1: Another committer from the project must review and vote + using Bugzilla (see below).
    • After RC2: Another committer from the project and a project lead must review and vote +1 after reviewing the bug for appropriateness and risk.

Bugzilla Usage for RC Fixes

Committers can signify their approval for submitting fixes as required after RC1 by simply indicating +1 in a comment.

Bugzilla has a flag feature that is to be used for obtaining PMC approval. Enter the email address of the PMC member you are requesting approval from and submit. The PMC member is notified via email and will change the flag from '?' to '+' or '-' as appropriate.

Backporting fixes for service releases

  • Bugfixes should be backported to the maintenance branch only if they match the criteria above.
  • A review is required if bug fixes should be backported.
  • A patch must be attached to every bug which is backported.
  • If a bug has been backported for a service release, a tag of the form "srX_Y_Z" must be added to the status whiteboard field in bugzilla, where X_Y_Z is the service release number without dots (e.g. "sr0_10_1" for Gyrex 0.10.1).
  • To request backporting for a service release, a tag of the form "srX_Y_Z?" can be used.

See Also

Back to the top