Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Cc: overlays@g.o, qa@g.o
Subject: [gentoo-project] RFC: a few new rules for repositories in repositories.xml
Date: Fri, 15 May 2015 05:19:24
Message-Id: 03cbb7fa-23df-4b66-8e81-0ee2cf528968@email.android.com
1 Hello,
2
3 As some of you may have noticed, I've been doing some Overlays team work lately. During that, I've been noticing various degree of QA
4 issues with a lot of overlays, and getting them fixed required a lot of effort. Worst of all, having no clear policies I was pretty much asking, demanding and setting up blurry deadlines of my own reason.
5
6 I'd like to change that and get a few new official rules for Gentoo repositories into place. Those rules would apply to all repositories in repositories.xml -- both new ones and the existing ones (with some grace period, perhaps).
7
8
9 The suggested new rules are, followed by rationale:
10
11 1. All repository owners need to have a Gentoo Bugzilla account associated with the owner e-mail.
12
13 Rationale: mail is unreliable. I've been reporting issues via mail for some time already, and many of the mails have simply been missed (as it
14 turned out in later conversation). Bugzilla is more secure in this regard, and it also provides a public log of the issue and the activity on it.
15
16
17 2. Each rule violation is reported to the repository owners via Bugzilla [mail if no Bugzilla account during transition period]. The owners need to reply to the report in 14 days. The underlying issue needs to be fixed in 30 days. If either of the deadlines is not met, the repository is removed from repositories.xml.
18
19 Rationale: re-adding a repository is low-effort. Since the rules defined here are rather of major importance and the violations are easy to fix, there is no point in allowing humongous deadlines.
20
21
22 3. Repositories can be distributed via cvs, git, rsync or svn protocols [TODO: possibly more]. Only the default branch can be used. The first specified URI must be valid, and allow anonymous access.
23
24 Rationale: we shouldn't depend on layman to do all the work. Portage has its own syncing code, and it's a subset of layman's features. Would be nice to be able to reliably use it.
25
26
27 4. Repositories need to conform to at least basic rules enforced by the PMS or the common subset of features supported by Portage, pkgcore and Paludis.
28
29 Rationale: we don't want things to blow up hard in users' faces when they happen to add some repository. Alternatively, we need to mark non-PMS repositories as such.
30
31
32 5. Repository name specified in repo_name must match the one used in repositories.xml.
33
34 Rationale: repos.conf entry needs to know repository name before initial sync.
35
36
37 6. Repository must specify valid masters. All masters must be available in repositories.xml.
38
39 Rationale: repositories are kinda useless without their masters. We need to have a common definition namespace for them, and repositories.xml is good for it. Eventually, we may have layman add masters recursively. Note that 'gentoo' is in repositories.xml these days as well.
40
41
42 What are your thoughts?
43
44 --
45 Best regards,
46 Michał Górny
47
48
49
50 --
51 Michał Górny

Replies