Changes between Version 9 and Version 10 of WikiStart/OngoingWork/GitHubMigration


Ignore:
Timestamp:
05/15/14 11:23:51 (5 years ago)
Author:
sylvain.joyeux
Comment:

Moved the github process description as RG9

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart/OngoingWork/GitHubMigration

    v9 v10  
    1 = Github-based Process = 
    2  
    3 This is meant to describe how information / issue tracking / ... will be done once we migrate to github. The rationale as well as the process for migration is described below. 
    4  
    5 == General Process == 
    6  
    7  - 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) 
    8  - Rock is split into multiple sub-projects (rock-base, rock-drivers, ...). There is one organization per sub-project. 
    9  - a set of Rock administrators (2-3 people at all times) are part of all organizations' Owners team. Their role is to: 
    10    - create new repositories 
    11    - apply merge requests on the package_set repository 
    12    - apply merge requests on repositories they do not maintain '''if''' 
    13      - the package maintainer is not available 
    14      - the patch is critical (has a big impact on many other packages, or on the build of rock itself) 
    15  - 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: 
    16    - 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. 
    17    - apply / reject merge requests to '''his''' package, manage issues 
    18  - a special team, 'Core' is given rights to the repositories of this sub-project that are considered part of the Rock core, as e.g. gui/vizkit, gui/vizkit3d, drivers/aggregator, drivers/transformer, ... 
    19  
    20 == Really Core Packages == 
    21  
    22  - the "really core" packages are handled differently, due to their pretty sensitive nature. This includes 
    23    - base/types 
    24    - base/orogen/types 
    25    - base/orogen/std 
    26    - all package sets 
    27    - buildconf 
    28    - autobuild 
    29    - autoproj 
    30  - only the Owners team have push rights to these. People in this team don't have special decision power, they are purely gatekeepers. 
    31  - 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. 
    32  - in addition, modifications of types and/or addition of new types to base/types MUST be discussed on the rock-dev ML. 
    33  
    34 == Core Packages == 
    35  - the non-really core packages (toolchain, tooling, vizkit, transformer, doc, ...) need also to be handled with care, but less strictly than the base packages 
    36  - a Core team is created in all relevant sub-projects. People in this team are given the same role than with the Owners team, but in addition are also allowed to push directly. I would keep a separate team for the documentation as the people that contribute a lot to the code are most likely not intersecting with those that contribute to the website. 
    37  - "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. 
    38  
    39 == How to decide who goes in the special teams == 
    40  
    41  - the Owners team has really only an administration role. They should 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. Currently, the project's administration is really done by Sylvain and Thomas, so I would add them initially. We should look for volunteers to get at least one more (maybe two ?). 
    42  - the Core team should be composed by the people that contributed the most to the core packages... We'll let github tell us ;-) 
    43  - obvious for the Maintainers team, at the discretion of the maintainers for the Authors team. 
     1See also [wiki:Standards/RG9 the description for the github process] 
    442 
    453= Migration =