Project:GURU

From Gentoo Wiki
(Redirected from GURU)
Jump to:navigation Jump to:search
GURU
Description Ebuild repository entirely maintained by Gentoo users
Project email [email protected]
IRC channel #gentoo-guru (webchat)
Lead(s)
No lead election date set
Member(s)
Subproject(s)
(and inherited member(s)) 		(none)
Parent Project Gentoo
Project listing

The goal of the GURU project is to create an official repository of new Gentoo packages that are maintained collaboratively by Gentoo users. It follows the tradition of Sunrise project but aims to improve its maintainability by reducing the involvement of Gentoo developers and letting experienced contributors take care of reviewing work of others.

GURU project logo

Disclaimer

Please note that the GURU project is maintained and reviewed entirely by Gentoo users. It is only subject to minimal supervision from individual Gentoo developers, and is not supported by projects such as Gentoo Security. While our Trusted Contributors do their best to keep GURU safe, it is possible for it to contain vulnerable, badly broken or even malicious software. You are using it on your own responsibility.

Rules

Note
As of 2026-07-19, the rules for contributing to GURU have changed. Please make sure to read the new rules.

Every user willing to contribute to the GURU project needs to explicitly agree with the following rules.

  1. The purpose of GURU project is to maintain a repository that can be reasonably used by Gentoo users. All contributors are responsible for ensuring that the repository is safe to use and free of malicious or severely buggy software.
  2. GURU is an official Gentoo project, and is therefore bound by the official Gentoo policies. This includes but is not limited to:
  3. There are three classes of users in GURU:
    1. Regular contributors that are permitted to commit to the development (dev) branch. They can also review and merge pull requests and patches, and suggest when new contributors are ready to join the project.
    2. Trusted contributors that gain additional privilege of merging commits into the reviewed (master) branch. They are also responsible for approving new access requests, settling disputes and voting on project policies.
    3. Gentoo developers who are responsible for processing new user requests, enforcement of regulations and taking care of emergencies.
  4. Contribution workflow
    1. All new commits must land on the dev branch.
    2. Trusted contributors regularly review the dev branch for any major issues, and fast-forward the master branch to it. In case of major problems on dev, reverting commits is permitted to unblock the fast-forward update.
    3. While not obligatory, all contributors are encouraged to hang around and communicate via #gentoo-guru (webchat) IRC channel.
    4. Contributions can also be submitted as pull requests or patches sent to the [email protected] mailing list. This is especially useful for new users, when submitting non-trivial changes to packages maintained by others and when help / review is needed. All experienced GURU committers are encouraged to review contributions, and merge them once a consensus is reached.
  5. Joining GURU
    1. Initially, GURU contributions are done through pull requests or mailing list patches. These can involve new packages or fixes to the existing packages. Please make sure to follow Gentoo policies and acknowledge that you have read and agree to these rules.
    2. After getting a few contributions merged, file an access request on Gentoo Bugzilla. Please include the name you will use to sign your commits, your public SSH key (if you don't have access to any git.gentoo.org repositories yet), the public OpenPGP key you will be using to sign commits and point us to how to find your contributions (the Codeberg/GitHub username, the e-mail address used to send patches). Continue contributing via PRs/patches after filing the access request.
    3. A Trusted Contributor or a developer will become your mentor, review your contributions and possibly point you towards a few additional tasks. Once they have verified your effort, they will approve the bug and a developer will grant your access.
  6. Additional membership information
    1. Experienced contributors with good track record of work can request the status of Trusted Contributor by filing an ascension request. This request will be vetted by other TCs, and handled by the developers afterwards.
    2. The contributor or TC status can be revoked by developers as a result of severe or repeated policy violations, or prolonged inactivity.
  7. Package requirements
    1. The primary purpose of GURU is to maintain packages not present in the Gentoo repository. Forking (overriding) actively maintained Gentoo packages into GURU is prohibited. If the package is moved to Gentoo, it should be removed from GURU. If a package is masked for removal in Gentoo, it can be imported into GURU immediately (provided that the most significant issues are addressed).
    2. Packages in GURU are to have ~arch keywords. Stable keywords must not be used, with the exception of special kinds of packages that always use stable keywords via eclasses (e.g. acct-* packages).
    3. Contributors should refrain from adding packages that they cannot reasonably maintain, due to, for example, the complexity, scope, or quantity of the added work. Adding rough drafts of ebuilds with the hope that someone else will fix them up and no intent of doing so yourself is not acceptable. Adding packages in bulk should be avoided.
    4. Packages in GURU must solve a problem that cannot be reasonably achieved using simpler methods. In other words, there should be some rationale for an ebuild to be an ebuild instead of, for example, a downloadable script or a config snippet.
    5. Gentoo users are allowed publish the software they created via GURU. Non-Gentoo users must not use GURU as an advertising platform for their new software.
    6. With very few exceptions, such as virtuals or meta-packages, new packages in GURU should have an upstream (meaning SRC_URI should usually be populated). Exceptions must be justified.
    7. News items and eclasses are permitted in GURU. Before adding one, it must be emailed to the [email protected] mailing list and the Trusted Contributors ([email protected]) for review and approval.
  8. Package maintenance
    1. While following Gentoo ebuild policies and quality standards is recommended, it will not be strictly enforced. More experienced users are encouraged to improve the quality of ebuilds in GURU, and less experienced users are encouraged to learn from those corrections.
    2. Packages in GURU are community maintained. While users are encouraged to list themselves as maintainers and take explicit responsibility for their packages, it is acceptable for others to commit improvements to those packages and to commit packages without an explicit maintainer. One should still both aim for consensus and also reach out to the current maintainer or previous folks who touched the ebuild as a courtesy.
    3. At the same time, users are asked to maintain respectful and professional behavior, and to attempt to maintain a good quality of GURU overall.
    4. Users that list themselves as maintainers must use an e-mail address known to Gentoo Bugzilla in metadata.xml and keep it up to date in case it changes. All GURU users are expected to be responsive to queries on Bugzilla.

QA

While project is maintained and reviewed entirely by Gentoo users, Tinderbox project builds GURU packages on a regular basis to find common mistakes.

Conflict resolution

If an unresolvable disagreement arises between (trusted) contributors or between contributors and users, follow the steps below:

  1. Involve (the other) Trusted Contributors via e-mail to the mailing list or bugs.gentoo.org. If this does not lead to an acceptable resolution then,
  2. Hold a formal vote on bugs.gentoo.org among the Trusted Contributors on how the conflict should be resolved. The issue may be escalated to the Gentoo Developers involved in GURU if this is the conclusion of the vote, or if the involved parties wish to appeal the conclusion of the vote.
  3. If the issue still cannot be resolved via discussion with the Gentoo Developers involved in GURU, then they too will hold a vote to decide how the matter should be resolved,

In this process, the following conditions apply:

  1. A decision to revoke access to the dev or master branch, whether temporarily or permanent, must involve the Gentoo Developers that are a member of the GURU project.
  2. A decision to permanently revoke access to the dev or master branch should be preceded by a formal warning, a preceding temporary suspension of access counts as a warning. Only in extreme cases, such as malevolent behaviour, may this warning be skipped.
  3. To keep track of them, formal warnings and suspensions are noted in the contributor's access request bug.
  4. A Trusted Contributor who is the subject of a vote, may not participate in this vote.
  5. Policies and guidelines of the Community Relations project with regards to developer-user conflict apply here as well.

Resources

Technical resources:

Commit feeds:

GURU guides:

Useful development documentation:

Retrieved from "https://wiki.gentoo.org/index.php?title=Project:GURU&oldid=1449629"