Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Please see github documentation for the details.

Traditional Git Development

There is also a traditional way how to collaborate using git. This method is rarely used. But we still support it if you happen to prefer this method. See Traditional Use of Git page for details.

Tips and Best Practice

...

Info
titleGithub, Gitlab and big evil corporations

Some people will certainly express concerns about our use of github. After all, github is a centralized platform. And as such, there are always concerns of abuse, monopolization and single point of failure. We are more than aware of such concerns. And we highly value project autonomy. Despite that we have decided that centralized platforms such as github are providing good value - if they are used in moderation.

We are using github to publish the code (git repositories) and to govern pull requests. We are not relying on github for anything else. We are not using github issues, wiki or any similar feature. And we do not plan to. Because we value our autonomy. Github was acquired by a certain corporation which has done questionable things in the past and there is no telling what will be done in the future. Therefore we need a freedom to evacuate our projects from github when things start to move in wrong direction. Git makes this easy, as migrating git repository is basically a question of a single push. Therefore we use github today, but it may be gitlab tomorrow and we may migrate to a completely self-hosted solution the day after. But the situation is quite different for github issues and wikis - those are not that easy to migrate. Therefore we do not use them at all. We still use github pull requests, though. Those provide very good value. And pull requests are temporary anyway - if handled correctly. Accepted pull requests are transformed into git history. And we do not rcare about refused pull requets that much. Therefore there is very little risk of losing pull request history. Everything we value is part of git and git is easy to migrate any time.

Traditional Git Development

There is also a traditional way how to collaborate using git. This method is rarely used. But we still support it if you happen to prefer this method. See Traditional Use of Git page for details.

Contributing

MidPoint project is open to contributions. However, there are some criteria and recommendations for contributing. Please have a look at Code Contribution Guidelines for the details.

Licence and Credit

MidPoint is developed under Apache Licence. By submitting your contribution to the main midPoint repository you agree to the terms of the Licence and you contribute your work under this licence. There is no other contributor agreement and we do not ask for copyright assignment. All work is licensed under the Apache licence. That's the only rule. We are very strict about maintaining midPoint open source character and therefore we will not accept any contribution under a different licence (using publicly available third-party open source libraries is OK as long as they are available under any compatible OSI-approved licence - except for hard copyleft licenses such as GPL). Each new contributed file must have appropriate header declaring licensing under Apache Licence otherwise the contribution might be refused.

Git maintains the commit meta-data of the original commit. And this is what will be recorded in the history trail of main midPoint repository. Therefore the original contributor will be recorded in each commit. Apart from this the contributors are free to add their names to the appropriate place in the file header (e.g. Java @author annotation) if they feel their contribution is big enough to justify it.

Development Guidelines

See

...

See Also