Github Repository Organization

MDSD-Tools Organization

All MDSD-Tools source code is located in the MDSD-Tools Github organization.

Currently, there are no specific schemes and rules for contributing to this GitHub organization, but if applicable, follow the rules and schemes that are defined for the Palladio GitHub Organization below.

Palladio Organization

All Palladio source code is located in the PalladioSimulator Github organization. A rule of thumb is that there is a separate repository for every project that has an update site.

Naming Schema

To maintain clearness, we apply a naming scheme to all repositories and use Github topics to group repositories.

The naming schema is Palladio-Category-Name-Name2. Categories can be:

Category	Description
Core	Features that are essential for Palladio and can never be omitted.
Addon	Features that introduce new features to PCM but that do not fit in any other category.
Analyzer	Features that derive information about quality properties for given PCM models.
Simulation	Features that provide the simulation framework for analyzing PCM models.
QuAL	Features that record analysis results and provide analyses that derive quality metrics.
Editors	Features that provide editors for PCM models.
Bench	Projects that provide PCM features bundled read to use by users.
Supporting	Features that do not depend on PCM but are used by other Palladio features.
Build	Projects that support the build process including quality control of build results.

Folder Structure

The folder structure for your whole project (consisting of many plugins, features, ...) should adhere to the structure suggested by Dirk Fauth [1] in order to make life easier later. The suggested structure is as follows:

• Project Root
  • bundles (contains all plugin projects)
  • tests (contains all test projects)
  • features (contains all feature projects)
  • releng (contains helper projects and the update site project)
  • Eclipse Plugins
  • We assume several usage pattern for developing

Eclipse plugins.

We assume several usage pattern for developing Eclipse plugins.

• Tests are stored in separate Plugin Test Projects
• Source code is stored in a folder called test (restriction does not exist for Palladio projects)
• Generated source code is stored in a folder called src-gen
• Generated source code from Xtend is stored in a folder called xtend-gen
• These assumptions intentionally violate the prescribed project structure of Maven to better match commonly used Eclipse structures.

Default Content

Every repository has to contain a LICENSE and a README.md file. The license has to be either EPL for Palladio contributions or Apache for build system contributions available via Maven Central.

The readme file has to adhere to the following template:

# Project name
Short project description (might be copied from the addon description in our wiki)

## Documentation
For comprehensive documentation, please visit our [wiki page](https://sdqweb.ipd.kit.edu/wiki/Palladio_xyz).

## Support
For support
* visit our [issue tracking system](https://palladio-simulator.com/jira)
* contact us via our [mailing list](https://lists.ira.uni-karlsruhe.de/mailman/listinfo/palladio-dev)

For professional support, please fill in our [contact form](http://www.palladio-simulator.com/about_palladio/support/).

GitHub Topics

The topics we use on Github are:

Topic	Description
incubation	Experimental projects that are usually not yet shipped in Palladio releases.
third-party	Forked projects maintained or extended by Palladio developers.
build-system	Build-related projects.

Branch Protection

We do not allow commits to master without proper code review. Therefore, we have to create a branch protection rule. Go to Branches and use the Add rule button to create a new rule. Use the following template for creating the rule:

Option	Value
Apply rule to	master
Require pull request reviews before merging	☒
Required approving reviews	1
Dismiss stale pull request approvals when new commits are pushed	☒
Require review from Code Owners	☐
Restrict who can dismiss pull request reviews	☐
Require status checks to pass before merging	☐
Require signed commits	☐
Include administrators	☒
Restrict who can push to matching branches	☐

Disableing Branch Proctection for Administrators

For e.g. release, some changes are best done in batches, using scripts. For these kinds of changes, the branch protection rules need to be briefly adjusted, so the rule does not include administrators.

A script to disable the branch protection for administrators can be found here on SVN.

It is important to directly enable branch protection for administrators after changes are made.

Creating new Branch Protection Rules

In case new branch protection rules need to be created for all repositories, the same script from above can be used. Using the GraphQLquery language, branch protection rules can be created, even for branches that do not already exist.

However, changing branch protection rules with GraphQL, using a script is not straightforward. When changes to rules need to be made, use the old API, which is also used for disabling branch protection for administrators.