Developer
目录
GURU
GURU
GURU 项目的目的是创建一个由 Gentoo 用户合作维护的新 Gentoo 软件包的官方仓库。它遵循 Sunrise 项目的传统,但是旨在通过减少 Gentoo 开发者的参与并让有经验的贡献者来负责审核其他人的工作来提高其可维护性。
The regulations
每一个愿意贡献到 GURU 项目的用户都需要明确的同意以下规定:
- GURU 项目的目的是维护一个可以被 Gentoo 用户合理使用的仓库。所有贡献者都有责任确保仓库可以安全使用并且没有恶意活严重漏洞的软件。
- GURU 是 Gentoo 的官方项目,因此受 Gentoo 官方政策的约束。特别是,Copyright Policy(GLEP 76)对所有提交者都有约束力。
- 虽然遵循 Gentoo ebuild 的政策和质量标准是推荐的,但不会严格的强制执行。鼓励更有经验的用户更高 GURU 中 ebuild 的质量,更里缺乏经验的用户从这些更正中学习。
- GURU 中的软件包应具有
~arch
关键字。不得使用 stable 关键字。 - GURU 中的软件包由社区维护。虽然鼓励用户将自己列为维护着并对其软件包承担明确的责任,其他人也可以对这些软件包进行改进,而且提交软件包而无明确的维护着也是可以接受的。
- 同时,用户被要求保持尊重和专业的行为,并尝试对 GURU 整体保持一个良好的质量。
- GURU 的主要目的是维护不在 Gentoo 仓库中的软件包。Forking(overrding)活跃维护的 Gentoo 软件包到 GURU 中是禁止的。如果软件包被移动到 Gentoo,那么它应该从 GURU 中删除。
用户角色和责任
GURU 将用户分为三类:
- 常规用户 允许提交到开发(dev)分支。
- 信任用户 获得附加的合并提交到已审核的(master)分支的权限。
- Gentoo 开发者 负责处理新用户的接受、规定的执行和紧急情况的处理。
新的贡献者通过在 GURU 产品中提交 bug 并声明同意规定来请求访问。Gentoo 开发者授予访问仓库的权限。
常规贡献者在开发分支执行他们的工作。这些工作之后被信任贡献者和/或 Gentoo 开发者审核。他们要么通知作者必要的修改,要么自己修复 ebuild。无论何时最终状态足够好,他们就会合并这些修改到已审核的(master)分支。
信任贡献者状态由 Gentoo 开发者根据之前在 GURU 中所做的出色工作授予。信任用户通常被期望负责确保仓库免于恶意或其他危险的代码,并阻止它通过审核分支到达最终用户。
Gentoo 开发者可以在闲暇时间加入项目。他们的主要角色是处理来自用户的技术请求,授予信任贡献者权限以及防止滥用。
Generating/Managing GLEP 63 based OpenPGP keys
https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys
# 生成新的GPG key gpg --expert --full-generate-key # 显式现有的GPG keys gpg --list-keys gpg --list-secret-keys gpg --list-secret-keys --keyid-format LONG # 提交key到keyserver gpg --keyserver hkps://hkps.pool.sks-keyservers.net --send-keys KEY-FINGERPRINT # 生成ssh-key gpg --export-ssh-key <KEYID>
git setup
# git local config git config --local pull.ff only git config --local pull.rebase preserve git config --local commit.gpgsign 1 git config --local push.gpgsign 1 # warning: git rebase --preserve-merges is deprecated. Use --rebase-merges instead. # git user information git config --local user.name "Your Full Name" git config --local user.email "someone@example.com" git config --local user.signingkey KEY-FINGERPRINT # /etc/portage/make.confRepoman setup for committing PORTAGE_GPG_KEY='KEY-FINGERPRINT' DCO_SIGNED_OFF_BY='Your Real Name <someone@example.com>'
Committing
# stage changes git add <files> # check staged changes git status # use repoman for committing repoman -dx commit # alternatively (or whenever direct use of Repoman is insufficient, repman -dx full git commit -s # after committing, look through changs git log -p # finally push them git pull --rebase && git push
Resources
GURU guides:
- /Information for Contributors
- /Information for Trusted Contributors
- /Information for Gentoo Developers Useful development documentation:
- Devmanual — Gentoo Developer Guide
- Proxy-maint project user guide (not strictly suited to GURU but contains many useful tips)
- GLEP 76: Copyright Policy (obligatory)
- GLEP 63: Gentoo OpenPGP Policies (recommended)
- GLEP 66: Gentoo Git Workflow (recommended)
Links
- Become a developer
- Project:GURU
- Project:Proxy Maintainers
- Project:Recruiters
- Project:GitHub
- Gentoo GitHub
- Gentoo git workflow(Not maintained by Gentoo developers)
Proxy Maintainers
Intro
Proxy Maintainers 项目是有兴趣对于贡献未维护的包到官方 Gentoo 仓库的用户的主要联系点。我们帮助用户好像他们自己一样采用一个包,无论是以前放弃的,还是新包。我们还提供了一个框架,用户可以在其中帮助开发人员在 Proxy Maintainters 项目的监督下维护他们自己的包。
成为 Proxy Maintainer 需要什么
热情 :用户关于你的包的问题将直接指向你。我们希望你能享受维护,而不觉得这是一件苦差事。
团队合作 :我们的开发者团队将会协助和指导你确保你的提交符合 Gentoo QA 政策标准。我们将确保我们的反馈富有成效,并且你受到尊重。
责任 : Proxy Maintainer 希望维护一个包,对任何的相关 bugs 负责,并长期保持它为最新状态。 Proxy Maintainer 在提交之前在他的本地 overlay 中 仔细地测试包 。
耐心 :包维护包括与开发者、用户和上游程序员沟通。有时你的 提交可能需要大量的工作才能满足 Gentoo QA 标准 。这可能令人沮丧,但是 Proxy Maintainers 项目将在整个尽最大努力帮助 Proxy Maintainer。
入门
- 如何找到有趣的ebuild来贡献?
- 作为Proxy Maintainer工作的最佳工具是什么?
- Proxy Maintainers如何与开发者在一个包上共同工作?
- Proxy Maintainer的FAQ和常见错误
- Gentoo 新(代理)维护者在 wiki 中的常见缩写列表
资源
- 关于Proxy-Maint所有事情的指南:这里你会找到与开发者和项目进行交互的有用信息。你会找到参与项目时要遵循的指南以及所有参与者都受约束的政策。还有关于 Proxy Maintainers 项目的 QA 标准以及如何实现这些标准的信息。
- Git指南:通过 pull requests 和 补丁提交为项目做出贡献 。
- 项目政策和指南:鼓励用户和开发人员熟悉项目的内部工作。