We use Git and source control tool.

Originally, the primary source control tool at OPS4J was SVN.

Git

In September 2010 we started an evaluation phase of using GIT as a primary SCM for some projects.
Because GIT is decentral SCM, you don't need a (by definition) a central repository instance.
However, as a community, you want to have a shared repository that materializes the "official" codebase. Currently we use GitHUb as the host for GIT based projects at OPS4J.

The official OPS4J Github project location is: https://github.com/ops4j/.
This is Github for Organizations as its account type, so that OPS4J is just a repository, not a user that can commit by itself.

Its not hosted on the OPS4J Servers ?

No.

Why Github ?

• Its the (current) center of the Git Universe (in terms of buzz)
• It works out of the box
• It decentralizes OPS4J infrastructure and maintainance requirements
• It connects OPS4J with the Github crowd (visibility)

How do i check out ?

Short answer (for example for Pax Exam):

git clone git@github.com:ops4j/org.ops4j.pax.exam2.git

Long Answer:
Read Getting started with Git and GitHub

Which projects have been moved already ?

The following - formally hosted in SVN - projects have been imported into Github already:

The old SVN locations still exist but will be read only.

When importing SVN repos into github, please use the --authors-file flag providing valid svn-user to github-user mappings.
Currently we maintain this mapping at http://github.com:ops4j/git-helpers.

How do I commit ?

First, you'll need an account on Github. We have not bound the authentication mechanism to our Single-Sign-On solution that works with our self-hosted SVN.
But because you need to exchange your keypair with Github anyway its probably necessary to contact the Github site yourself anyway.

As soon as you have an account, you can fork any OPS4J project and happily commit away.

Wait, i cannot commit to the OPS4J Repo ?

Well, now to the interesting parts. Github usually recomments (and supports via a nice WebUI) a Pull-Request based contribution model.
This also works out-of-the box with OPS4J projects.

But this is for sure not the way Zero Barrier is being enforced at OPS4J. Its more like a "submit patch" model (process wise).
Instead, we will grant each developer asking for commit rights the required karma to directly push changes to the OPS4J projects. You can request for karma by:

• asking on the Mailinglist
• issueing a Pull Request on Github. (we will give you karma and close the pull request so that you can push yourself)

We apologize we need this level of indirection. Its a technical drawback when compared to our SVN participation process. But if you like git, you probably already hang out on Github all day anyway.

What is OPS4J worth when hosting projects on Github anyway ?

You get

• Infrastructure like Jira, Confluence, Bamboo
• Existing upstream sync to Maven Central
• OPS4J karma
• a helpful community and a very responsive Mailinglist
• ..

for free.

Subversion

The SVN ROOT of the public repository is at;

https://scm.ops4j.org/repos/ops4j, browseable* here

Under the public root, we are suggesting the following layout, to promote the Code Ladder approach to development.

$ROOT/
     laboratory/                 - contains experiments.
         users/                  - area divided by users.
             <user>/             - one directory for each user conducting experiments.
     projects/                   - contains projects that are on the way to make it into products.
         <project>/              - one directory for each project.
     products/                   - products have developer community support and are stable
         <product>/              - one directory for each product
             dev/                - development tree for ongoing development of each product.
             qa/                 - stabilization work prior to releases.
                 <tag>           - one directory for each QA release, named same as release tag.
             milestones/         - read-only repository of milestone releases.
                 <tag>           - one directory for each milestone release, named same as release tag.
             releases/           - read-only repository of official releases.
                 <tag>           - one directory for each milestone release, named same as release tag.
     retirement/                 - read-only repository of end-of-life projects and products.
         <product>/
         <project>/

The users/ directory contains a folder for each user and the user is free to organize it in any way. All new efforts must start in here, and only after an additional developer is working on the codebase, can it be promoted to a project.

If you have signed up here , you can create your folder under the users/ directory by the usual SVN command:

svn mkdir -m "Add your comment here." --username <username> --password <password> https://scm.ops4j.org/repos/ops4j/laboratory/users/<name-or-id>

Under projects/ there will be one directory for each project that gets started. Projects that don't have developer activity in 6 months is moved to retirement/ . The developers of the project collectively decide how to organize, but should consider to organize according to the requirements of the product/ step. Projects seeking promotion to product needs; 5 active developers, the project organized as a product, operate a separate mailing list (ask at infra@lists.ops4j.org), and have a minimum of 200 mails a month over at least two months. This ensures strong participation and long-term sustainability.

Under products/ you can find projects that have shown sustainability, long-term commitment from a flock of developers and stability. Daily development happens in the dev/ directory. qa/*contains work that is needed to get a milestone through the door. If there are no issues with the milestone, it is promoted to a release. The release must be binary identical (except versioning numbers) with the milestone it is based upon. Products reaches end-of-life after 12 months of no user support requests, and then placed into the *retirement.

And finally, projects and products that are no longer actively supported, are put into the retirement/. Projects are put in there more quickly (6 months) than products, not only because products has stronger developer community, but also as an assurance to the user community.