Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Gemini/DBAccess/CommitterGuide"
m |
|||
| Line 1: | Line 1: | ||
| − | + | = Gemini DBAccess Committers Guide = | |
| − | |||
| − | |||
| − | + | Welcome to Gemini DBAccess! As a committer you have demonstrated that you are not only interested in the project but are willing to contribute some of your time and energy to improving and advancing it. Thanks for that. | |
| − | that you are not only interested in the project but are willing to contribute | + | |
| − | some of your time and energy to improving and advancing it. Thanks for that. | + | |
| − | |||
| − | |||
| − | |||
| + | This page contains some hints and helps to get you up to speed and on your way. | ||
| − | |||
| − | |||
| − | + | === Source Repository === | |
| − | + | *http://git.eclipse.org/c/gemini.dbaccess/org.eclipse.gemini.dbaccess.git/ | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | === Communication === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Gemini is a multi-faceted project, with multiple subprojects that work together. The most important way to achieve this is to ensure there is regular communication not only with other team members but with members of the other teams. This is achieved in 3 different ways: | |
| − | + | 1) Project Conference Calls | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The Gemini team has a regular conference call that is open to both committers and community members alike (although in practice consumers rarely join). Comitters are strongly encouraged to be on this call as it is the primary way that important issues are discussed and resolved. See the wiki http://wiki.eclipse.org/Gemini/Meetings for the call details, agenda for the next call, and minutes of previous calls. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | 2) Gemini Dev List | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The dev list can be used to ask questions or bring up issues to the Gemini DBAccess subproject or the Gemini project at large. Committers should subscribe to the dev list (https://dev.eclipse.org/mailman/listinfo/gemini-dev) and participate in the discussions. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | 3) Bugzilla threads | |
| − | + | ||
| − | + | Bugzilla is used to track bugs and issues and there are often bug-related discussions. Avoid having these discussions in email since the discussion has value worth capturing and should be associated with and locatable from the bug under discussion. | |
| − | + | === External Contributions === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | External code must come through the Eclipse IP process (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf). Bugs must be filed by the contributor, with the code attached. Contributers should have been the primary authors of the code, and the code should be approved by the project lead before being committed to the repo. | |
| − | + | === Committing Code === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | All code that is being committed to the Gemini DBAccess repo should have an associated bug or enhancement request in Bugilla. The code should be revewed by another member of the team and have appropriate tests in place before being committed. | |
| − | + | === Project Builds === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Builds are done by individual developers using Eclipse. To build Gemini DBAccess import the DBAccess Eclipse project and build from within Eclipse. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | The Gemini DBAccess team is not currently big enough to experience checkin collisions, but this highlights the importance of communication. If a checkin collision should occur, contact the team member you are colliding with and work out a suitable solution. It will likely just involve doing a simple managed merge. | |
| − | + | ||
| − | + | ||
| − | + | === Dependencies === | |
| − | + | Gemini DBAccess depends on JDBC drivers that might not be part of the delivered bundle. In that case, the JDBC driver bundle has to be downloaded separately. The OSGi JPA classes are also required and are currently checked in the repo. Potential new dependencies should be discussed on the dev list before entering CQ requests. | |
| − | + | ||
| − | + | ||
| − | + | === Decision Making === | |
| − | + | We try (and have been successful up to this point) to achieve consensus around any issues and decisions that come up. This implies that there be flexibility on the part of all those involved. Stances taken based on pride or preconception are not productive and only serve to make issues more difficult to resolve. | |
| − | |||
| − | [[Category: | + | |
| + | In the event that a decision cannot be reached by consensus then a simple polling of the committers will be taken, with the project lead having the right to exercise a veto. | ||
| + | |||
| + | === Release Process === | ||
| + | |||
| + | Releases should be discussed and included in the project plan. The release process must include an Eclipse release review as dictated by http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews. | ||
| + | |||
| + | === Resources === | ||
| + | |||
| + | A number of developer resources are available on the Eclipse wiki: http://wiki.eclipse.org/Development_Resources. | ||
| + | |||
| + | [[Category:Gemini_DBAccess|DBAccess]] | ||
Revision as of 10:23, 4 April 2012
Contents
Gemini DBAccess Committers Guide
Welcome to Gemini DBAccess! As a committer you have demonstrated that you are not only interested in the project but are willing to contribute some of your time and energy to improving and advancing it. Thanks for that.
This page contains some hints and helps to get you up to speed and on your way.
Source Repository
Communication
Gemini is a multi-faceted project, with multiple subprojects that work together. The most important way to achieve this is to ensure there is regular communication not only with other team members but with members of the other teams. This is achieved in 3 different ways:
1) Project Conference Calls
The Gemini team has a regular conference call that is open to both committers and community members alike (although in practice consumers rarely join). Comitters are strongly encouraged to be on this call as it is the primary way that important issues are discussed and resolved. See the wiki http://wiki.eclipse.org/Gemini/Meetings for the call details, agenda for the next call, and minutes of previous calls.
2) Gemini Dev List
The dev list can be used to ask questions or bring up issues to the Gemini DBAccess subproject or the Gemini project at large. Committers should subscribe to the dev list (https://dev.eclipse.org/mailman/listinfo/gemini-dev) and participate in the discussions.
3) Bugzilla threads
Bugzilla is used to track bugs and issues and there are often bug-related discussions. Avoid having these discussions in email since the discussion has value worth capturing and should be associated with and locatable from the bug under discussion.
External Contributions
External code must come through the Eclipse IP process (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf). Bugs must be filed by the contributor, with the code attached. Contributers should have been the primary authors of the code, and the code should be approved by the project lead before being committed to the repo.
Committing Code
All code that is being committed to the Gemini DBAccess repo should have an associated bug or enhancement request in Bugilla. The code should be revewed by another member of the team and have appropriate tests in place before being committed.
Project Builds
Builds are done by individual developers using Eclipse. To build Gemini DBAccess import the DBAccess Eclipse project and build from within Eclipse.
The Gemini DBAccess team is not currently big enough to experience checkin collisions, but this highlights the importance of communication. If a checkin collision should occur, contact the team member you are colliding with and work out a suitable solution. It will likely just involve doing a simple managed merge.
Dependencies
Gemini DBAccess depends on JDBC drivers that might not be part of the delivered bundle. In that case, the JDBC driver bundle has to be downloaded separately. The OSGi JPA classes are also required and are currently checked in the repo. Potential new dependencies should be discussed on the dev list before entering CQ requests.
Decision Making
We try (and have been successful up to this point) to achieve consensus around any issues and decisions that come up. This implies that there be flexibility on the part of all those involved. Stances taken based on pride or preconception are not productive and only serve to make issues more difficult to resolve.
In the event that a decision cannot be reached by consensus then a simple polling of the committers will be taken, with the project lead having the right to exercise a veto.
Release Process
Releases should be discussed and included in the project plan. The release process must include an Eclipse release review as dictated by http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews.
Resources
A number of developer resources are available on the Eclipse wiki: http://wiki.eclipse.org/Development_Resources.