wiki:WikiStart/OngoingWork/GitHubMigration

See also the description for the github process

Migration

Rationale

  • Github has become the place to go for open source development. We will fork github-hosted code (since all good open-source robotic software is hosted there). And we should make it easy for e.g. ROS users to fork our own libraries.
  • integrated bug tracking
  • much better handling of pull requests and, in general, code reviews. This is really an integral part of a normal software development workflow, and github does it very very well.
  • integration with other services as e.g. travis
  • we can use the migration to start enforcing push rights. The current model of "anybody that has some push rights can push anywhere" does not work anymore (at least not for core packages). The general idea is that a package official maintainer will be admin on a repository and will have the power to manage the rights for this repository (in other words, it will be up to him).

OpenDFKI

  • cross-package bugs / tickets a few tickets are currently cross-package. It is really rare: when there is some true cross-package work, it is usually done using a wiki page. We will not have a replacement for these on github, but I would suggest that we simply create one ticket per affected package and cross-reference them using hyperlinks.
  • the wiki should for now stay where it is as there is no replacement in github. By having removed the bug tracker, we could move to a pure-wiki interface which would allow us to get rid of trac, and un-clutter the wiki interface.
    • UPDATE created a rock-robotics/doc repository and propose to use this as the main Rock wiki. Moreover, there are ways to export a trac wiki to github [1]

Migration Process

  • create one github organization per package category (i.e. rock-base, rock-toolchain, rock-drivers, ...) to match what is currently on gitorious
  • start by migrating core packages that should anyway be modified by only a few people (few people affected if it goes wrong), and slowly go from there to the rest of rock. I would start with the autoproj package sets, rock-base and rock-toolchain.
  • the migration of the rest of the packages would be done by the package maintainers (thus allowing us to check that every package has a meaningful maintainer), "gently" influenced by the rest of the rock developers.
  • The Owners team would contain a tiny number of people that are given push rights to everything. They should understand that their goal is to fix critical problems when maintainers are not available (e.g. autoproj configurations that cannot be loaded, thus affecting everybody) NOT to vet non-critical modifications to packages. With great power ... Note that the people that run the release scripts will have to be part of the Owners team (they need to be able to update the stable branch of all packages).
  • new repositories are given to push rights on new packages: maintainers and the rock-su team
    • UPDATE there is no way to assign rights per-user, only per-team. We should probably have a team of "maintainers" per subproject (== the maintainers of all the packages in this project) and make sure that everyone understands that they should not push to other people's repositories without using PR.
  • autoproj must point to github as soon as a package has been moved there. We really should avoid having two unsynchronized repositories. This is going to be tricky for the rock package set, but IMO manageable.

Handling of core / essential packages

  • for core packages (rock-base, parts or all of rock-toolchain and some other core packages like vizkit*, iodrivers_base, aggregator, transformer), I propose that NO commits should be added without review by somebody else. This means that nobody should push without a merge request and having someone else ack the PR. This seems to be doable in rock-base, as all packages already have three-four "non-trivial" committers. The issue with rock-toolchain is that some packages (typelib, orogen) can ATM only be reviewed by Sylvain (which means that he can't use the PR system ...).
  • for the rest, push rights should be managed by the package's maintainer (he decides who is
  • (Sylvain) I would like that using forks and pull requests gets the norm. Would like to keep the "official" Rock repositories clear of extensive branching, as it gets hard to track what happens, and by whom, really hard. Github is awesome when it comes to forking / PR management.
Last modified 5 years ago Last modified on 05/15/14 11:23:51