Archive:Development/Tutorials/Git/KdeOnGit: Difference between revisions

    From KDE TechBase
    (restored intro, removed non-kde kde projects)
    No edit summary
    Line 8: Line 8:
    * contributing:
    * contributing:
    ** quick guide to gitorious website (copy content from amarok) (this should probably be spread between this page and the [[Development/Tutorials/Git/Pushing|Pushing]] one.)
    ** quick guide to gitorious website (copy content from amarok) (this should probably be spread between this page and the [[Development/Tutorials/Git/Pushing|Pushing]] one.)
    ==How KDE projects on Gitorious are set up==
    First up, a brief description of the Gitorious.org user and permission model:
    * Individual user accounts can be organized into teams. Teams have members and administrators. Administrators can add new members and administrators, as well as edit a team's description.
    * A project can be owned by either a team or an individual user account. A project can have one or more repositories.
    * Any individual repository has a list of collaborators. A collaborator can be either a team or an individual user account and can any combination of these three flags: commit (allows pushing commits), admin (allows editing the repository's settings, including the collaborator list, and description) and review (allows processing merge requests).
    KDE currently operates the [http://gitorious.org/+kde-developers kde-developers] and [http://gitorious.org/+kde-sysadmin kde-sysadmin] teams on Gitorious.org, as well as several <appname>-reviewers teams (e.g. [http://gitorious.org/+konversation-reviewers konversation-reviewers]. The purpose of each of these can best be illustrated by examining how a KDE project on Gitorious.org has to be set up:
    - The project is owned by kde-developers.
    - The repositories belonging to the project have the 'kde-developers' team as a collaborator with the 'commit' permission bit.
    - The repositories also have 'kde-sysadmin' as a collaborator, with the 'admin' permission bit.
    - And they have an '<appname>-reviewers' team as a collaborator with the 'review' permission bit.
    - They also optionally have one or more key developers of the project as collaborators with the 'admin' permission bit.
    Commit access is thus exclusively handled via kde-developers, and any member of kde-developers can commit to any KDE repository. Getting into kde-developers is done by [https://bugs.kde.org/enter_sysadmin_request.cgi?component=gitorious filing a KDE sysadmin request] against the gitorious component, which is then implemented by one of the administrators of the kde-developers team.
    The kde-sysadmin team exists for the purpose of making sure KDE's sysadmin squad can edit all KDE repositories on Gitorious.org, to fix issues or help people in a bind.
    The '<appname>-reviewers' teams were originally created to be able to remove the 'review' permission bit from kde-developers for all the repositories, because otherwise every kde-developers member got email notifications about every merge request for every project. So someone with no interest in Amarok or Konversation would still get MR mail about them. Project-specific reviewers teams solve that routing problem. The reviewers teams usually have all the core developers from a project as members, and are administrated by one or more key developers.
    Now, about those optionally-added key developers with the 'admin' permission bit: Pushing a tag into a repository requires being allowed to do a "force push". Force pushing can be enabled/disabled on a per-repository basis on Gitorious.org by anyone who has the 'admin' permission bit for a repository. As outlined above, this currently means every member of the kde-sysadmin team - as well as one or more key developers from a given project that have been added individually with the 'admin' permission bit. Thus the the main motivation for this is to allow projects to push tags without having to involve KDE's sysadmin team.


    ==Projects already on Gitorious==
    ==Projects already on Gitorious==

    Revision as of 02:22, 3 March 2010

    Currently, Amarok and Konversation are testing out git to help with KDE's migration. There are also one or two kde-related projects that have started on gitorious (although this is *not* recommended yet!)


    TODO:

    • Explain where to find various kde projects and modules.
    • Explain how to clone them.
    • readonly-use guide
    • contributing:
      • quick guide to gitorious website (copy content from amarok) (this should probably be spread between this page and the Pushing one.)

    How KDE projects on Gitorious are set up

    First up, a brief description of the Gitorious.org user and permission model:

    • Individual user accounts can be organized into teams. Teams have members and administrators. Administrators can add new members and administrators, as well as edit a team's description.
    • A project can be owned by either a team or an individual user account. A project can have one or more repositories.
    • Any individual repository has a list of collaborators. A collaborator can be either a team or an individual user account and can any combination of these three flags: commit (allows pushing commits), admin (allows editing the repository's settings, including the collaborator list, and description) and review (allows processing merge requests).


    KDE currently operates the kde-developers and kde-sysadmin teams on Gitorious.org, as well as several <appname>-reviewers teams (e.g. konversation-reviewers. The purpose of each of these can best be illustrated by examining how a KDE project on Gitorious.org has to be set up:

    - The project is owned by kde-developers. - The repositories belonging to the project have the 'kde-developers' team as a collaborator with the 'commit' permission bit. - The repositories also have 'kde-sysadmin' as a collaborator, with the 'admin' permission bit. - And they have an '<appname>-reviewers' team as a collaborator with the 'review' permission bit. - They also optionally have one or more key developers of the project as collaborators with the 'admin' permission bit.

    Commit access is thus exclusively handled via kde-developers, and any member of kde-developers can commit to any KDE repository. Getting into kde-developers is done by filing a KDE sysadmin request against the gitorious component, which is then implemented by one of the administrators of the kde-developers team.

    The kde-sysadmin team exists for the purpose of making sure KDE's sysadmin squad can edit all KDE repositories on Gitorious.org, to fix issues or help people in a bind.

    The '<appname>-reviewers' teams were originally created to be able to remove the 'review' permission bit from kde-developers for all the repositories, because otherwise every kde-developers member got email notifications about every merge request for every project. So someone with no interest in Amarok or Konversation would still get MR mail about them. Project-specific reviewers teams solve that routing problem. The reviewers teams usually have all the core developers from a project as members, and are administrated by one or more key developers.

    Now, about those optionally-added key developers with the 'admin' permission bit: Pushing a tag into a repository requires being allowed to do a "force push". Force pushing can be enabled/disabled on a per-repository basis on Gitorious.org by anyone who has the 'admin' permission bit for a repository. As outlined above, this currently means every member of the kde-sysadmin team - as well as one or more key developers from a given project that have been added individually with the 'admin' permission bit. Thus the the main motivation for this is to allow projects to push tags without having to involve KDE's sysadmin team.


    Projects already on Gitorious

    • Amarok - KDE's favorite music player.
    • Konversation - an IRC client for KDE.
    • kde-qt - KDE’s copy of Qt, containing the latest release, plus patches for Qt that haven’t been accepted (yet) by Qt Software.

    FIXME: Is this a KDE project? Why are permissions not set for kde-developers?

    • Project Silk - We've been working with gitorious as an experiment.

    http://gitorious.org/+kde-developers has a more up-to-date list of kde-run projects. However, that list includes projects that don't use kde frameworks (like KDE developers' personal projects), and experiments, and isn't sorted in any way. We plan to have a better directory of kde-related projects once git.kde.org is up.