GitHub-based Development Process

This page describes the (few) rules for Rock development on GitHub. In particular, it talks about:

  • how to use issue tracking
  • how to manage permissions on Rock repositories

General Process

  • issue tracking is done using github issue tracker. If some problems are truly cross-package, create one ticket per package and make them reference each other (github-flavored markdown allow to easily cross-link)
  • Rock is split into multiple sub-projects (rock-base, rock-drivers, ...). There is one organization per sub-project.
  • a set of Rock administrators (2-3 people at all times) are part of all organizations' Owners team. Their role is to:
    • create new repositories
    • apply merge requests on the package_set repository
    • apply merge requests on repositories they do not maintain if
      • the package maintainer is not available
      • the patch is critical (has a big impact on many other packages, or on the build of rock itself)
  • package contributors are given push rights by being put into the sub-project's "Authors" team. This means that they can theoretically push to any repository in the sub-project. This is a github limitation. One should realize that and restrict himself to the repositories for which he is known to be a contributor.
  • the official maintainer of a given package gets into the sub-projects "Maintainer" team, meaning that he theoretically can modify any repository in the sub-project. This is a github limitation. One should realize that and restrict himself to:
    • add people that he thinks should be allowed to push directly to the repositories he is responsible for as authors in manifest.xml. He then creates an issue on the sub-project's package_set repository so that the Owners add him to the Authors team.
    • apply / reject merge requests to his package, manage issues

Really Core Packages

  • the "really core" packages are handled differently, due to their pretty sensitive nature. This includes
    • base/types
    • base/orogen/types
    • base/orogen/std
    • all package sets
    • buildconf
    • autobuild
    • autoproj
  • only the Owners team have push rights to these. People in this team don't have special decision power, they are purely gatekeepers.
  • all changes (even those coming from people in the Owners team) should be reviewed through the pull request mechanism. It can be merged only if at least one other person has reviewed the patch, and if consensus is built about it. It does not mean that we have to have unanimity, but if there are disagreements, there should be a clear "winning" side (preferably on github to record it). Use the @people syntax to "ping" people in the discussion (making sure that the patch does get reviewed). People interested in the future of these packages should make sure they are notified when PR and issues are added to it.
  • in addition, modifications of types and/or addition of new types to base/types MUST be discussed on the rock-dev ML.

Core Packages

  • the non-really core packages (toolchain, tooling, vizkit, transformer, doc, ...) need also to be handled with care, but less strictly than the base packages
  • all core packages are part of the rock.core package set
  • a Core team is created in rock.core. People in this team are given the same role than with the Owners team, but in addition are also allowed to push directly.
  • a separate Documentation team is given full access to the website repository
  • "with great power ...". The goal is to keep the code quality high when it already is, and improve it when it is not. Even Core members should prefer a liberal use of code reviews through PR instead of directly pushing.

How to decide who goes in the special teams

  • the Owners team has really only an administration role. They do not have any special decision power, they are only gatekeepers making sure that some important rules (such as the review process for really important core packages) are followed. It should be composed of 3 to 4 people that showed that (1) they cared about Rock development, (2) code and architecture quality and (3) volunteer for the job.
  • the Core team should be composed by the people that showed that they both know the core packages codebase well enough, as well as the overall Rock architecture. They should have demonstrated their ability to provide consistently good code for the core packages (or have the right reflex to review through PR code that is of inadequate quality). In the end, the current Core team is the one that should decide who can be added and who should leave the team in the first place. It should be done by consensus, taking into account (also obviously) the opinion of the greater rock dev community.
  • the composition of the Maintainers team is pretty obvious
  • the Authors teams is composed at the discretion of the maintainers

Initial composition of special teams

  • The project's administration was done by Sylvain and Thomas before the migration to github. They form the initial Owners team
  • the initial Core team should be composed by the people that contributed the most to the core packages. see for the details of stats and the initial composition
Last modified 6 years ago Last modified on 03/19/15 17:14:08