Here you can find the development related issues when working with the Apache Marmotta source code and/or contributing to it.
The project team uses different mailing lists for internal communication:
Twitter (@ApacheMarmotta) is also used, but more for quick updates of the project and some informal communications.
In addition, the project uses the #apachemarmotta IRC channel at Freenode. Regular meetings are held there; logs are always published and sent to the mailing list to mitigate the barriers of people in different timezones.
The code is managed using Git, and you access the repository at:
git:https://git-wip-us.apache.org/repos/asf/marmotta.git
There you would find something similar to the following structure:
. |-- build |-- client |-- commons |-- extras |-- launchers |-- libraries |-- loaders |-- parent |-- platform `-- pom.xml
Where:
Apache Maven is used as integrated build system; check out how to build Marmotta from the source code.
Marmotta uses a Gitflow Workflow (read more), depicted by the diagram on the right, which uses the following framework:
The main git repository is being mirrored at GitHub (github.com/apache/marmotta), from where you could directly send us pull requests with your contributions or patches. Please, referencence an issue from Jira in the title of your pull request.
If you want to contribute documentation, this web site is our main documentation. Due some restriction of the Apache CMS, the code of the web site is available in a separated Subversion repository:
svn:https://svn.apache.org/repos/asf/marmotta/site/trunk
Marmotta continues the versioning structure of LMF. The base code was contributes from LMF 2.6.0, that’s why Marmotta started with version 3.0.0-incubating. Here the list of versions of Marmotta:
Apache Marmotta uses Jira for tracking bug reports and requests for improvements, new features, and other changes. The issue tracker is available at http://issues.apache.org/jira/browse/MARMOTTA, and is anonymous readable by everyone. An account is needed to create new issues or to comment on existing issues.
When reporting a new issue, please try to be as descriptive as possible. For instance, the issue summary should be a short and clear statement that indicates the scope of the issue; you are probably being too verbose if you exceed the length of the text field. Use the Environment and Description fields to provide more detailed information. Besides, use the right type and assigned to the corrrect component to allow the project to be more effective on its resolution. See below some additional information and guidelines on creating and managing issues.
When creating a new issue, select the issue type based as follows:
| Issue type | Description |
|---|---|
| Bug | Bug reports are used for cases where Marmotta fails not function as it should (as defined by some documentation). If you are not certain whether the issue you've found is actually a bug, please ask at the mailing list first for help. |
| New Feature | Use a feature request when Marmotta does not have some functionality you need. |
| Improvement | Use an improvement request to suggest improvements to existing features. Typical improvement requests are about updating documentation, increasing stability and performance, simplifying the implementation, or other such changes that make Marmotta better without introducing new features or fixing existing bugs. |
| Test | Use this type when contributing test cases for existing features. Normally test cases should be contributed as a part of the original feature request or as regression tests associated with bug reports, but sometimes you just want to extend test coverage by introducing new test cases. This issue type is for such cases. |
| Task | Used only for issues related to project infrastructure. |
Issue priority should be set according to the following:
| Issue priority | Description |
|---|---|
| Blocker | Legal or other fundamental issue that makes it impossible to release Marmotta code |
| Critical | Major loss of functionality that affects many Marmotta users |
| Major | Important issue that should be resolved soon |
| Minor | Nice to have issues |
| Trivial | Trivial changes that can be applied whenever someone has extra time |
Marmotta issues can transition through a number of states while being processed:
| State | Description | Next states in workflow |
|---|---|---|
| Open | The issue has just been created | In Pogress |
| In Progress | Work has started on the issue | Resolved, Open |
| Resolved | The issue has been resolved from the developers point of view. Documentation and Testcases have been created and updated as required. Issue is ready for release. | Reopened, Closed |
| Reopened | A resolved issue has been recognized to contain bugs or to be incomplete and thus has been reopened. | In Progress, Resolved |
| Closed | Work on this issue has finished and it is included in the release. | -- |
Users generally create issues and provide feedback while work on the issue is in progress. When the developer thinks the issue has been resolved, he resolves the issue. At this point, the user may test the resolution and reopen the issue if it has not really be solved. Otherwise the user may just acknowledge the fix.
Developers transition the issue through the workflow while working on it. When done with the issue, they mark the issue resolved with the appropriate resolution and ask the reporting user to confirm.
Issues are closed once the project against which it has been reported has been released. Issues once closed cannot be opened again. Rather new issues should be created against the new release to have broken implementations fixed or extended.
So far we are not following strick development practices, but for Java coding we heavily base it on the Code Conventions for the Java Programming Language published by Oracle.
When reporting a bug, requesting a feature or propose an improvement, it is a good thing to attach a patch to the issue. This may speed up issue processing and helps you being recognized as a good community member leading to closer involvement with Marmotta.
While there is no exact criteria for becoming a committer, there is a fairly obvious path:
For starters, one should be familiar with the Apache Way, especially the part about meritocracy.
Second, participate in the mailing lists, help answer questions when you can and do so in a respectful manner. This is often more important than writing amazing code.
Third, write code, add patches, stick with them and be patient. Add unit tests and documentation. In general, tackling 3 or 4 decent patches is where the bar is at, but it depends on the state of the project. In the earlier stages of the project, the bar is a bit lower, so it pays to join early!
Finally, it is then up to someone to nominate them to the PMC. Typically, one of the existing committers does this by sending an email to the private PMC mailing list and then the PMC votes on it. Nominations often occur internal to the PMC as well.