Gentoo Archives: gentoo-dev-announce

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev-announce <gentoo-dev-announce@l.g.o>
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev-announce] GLEP67 officially approved with 2-week deadline
Date: Tue, 12 Jan 2016 15:27:03
1 Hello, everyone.
3 With a little delay, I'd like to announce that the 2016-01-10 Council
4 meeting (log [1], no summary yet) has resulted in the current
5 wording of GLEP67 being approved ([2], not yet moved to [3]).
7 Considering the progress so far (tracked in [4]), the Council has set
8 the deadline for herd status updates to 2 weeks from the meeting
9 (2016-01-24). At this point, all metadata.xml files will be updated
10 automatically and their conformance to GLEP67 will become obligatory.
12 I will be explaining GLEP67 in detail sometime this week. For now, I'd
13 like to focus on necessary transition notes.
16 Implementation progress
17 =======================
19 I. Most of herds have been handled already (thanks, kensington!).
21 II. I've opened bugs for all offending projects and herds (list may be
22 outdated, I'd be doing a second check soon).
24 III. projects.xml should already be generated from wiki and distributed
25 via rsync & git mirror.
27 IV. willikins was given new !proj command to expand projects. I'm going
28 to start working on !meta today.
30 V. I've got necessary metadata.dtd updates on a branch. After merging
31 it to master, the new version will start being distributed and enforced
32 by repoman.
34 VI. I've sent small Portage update to the ml. However, it would be nice
35 if someone wrote full set of <maintainer/> checks for repoman, including
36 checking if type="project" maintainers are in projects.xml.
38 VII. All migration scripts are ready, and test conversions are available
39 for review [5]. I'm updating them every few days.
43 Required action from Gentoo developers
44 ======================================
46 In the following two weeks, developers have to ensure that:
48 1. all project pages list unique, dedicated e-mail addresses for
49 the projects, or no addresses at all. Sharing the same address between
50 multiple projects is forbidden, as is reusing developer's e-mail
51 address for a project. If necessary, ask Infra to create an alias for
52 you.
54 2. If a project wishes to maintain any packages, its e-mail address
55 needs to be registered on Bugzilla. Only Infra can create Bugzilla
56 accounts for, so ask Infra for it.
58 3. The fate of the remaining herds needs to be decided by their
59 maintainers and listed on the mapping page [6]. We will be using this
60 page when doing the automated metadata updates.
62 4. There can not be any 'rogue' maintainers left. In other words, all
63 packages need to be maintained by explicit people (developers or
64 proxied maintainers), or explicit projects. No 'dumb' aliases are
65 allowed.
68 Now, my automated conversion script gives three possibilities for each
69 herd:
71 a. mapping to a single project -- in this case all <herd/> occurrences
72 will be replaced by the matching project. Multiple herds can be mapped
73 into one project but we don't support splitting herd into more
74 projects.
76 b. Disbanding and replacing with maintainers -- in this case all
77 current herd maintainers (taken from herds.xml) will be put into
78 metadata.xml directly.
80 c. Disbanding with no replacement -- in this case, <herd/> will be
81 removed with no replacement. Some packages will become
82 maintainer-needed.
85 Whenever this is not sufficient for your herd, please update
86 the metadata beforehand, if possible. Don't create new herds, though.
87 If you need a new project, use plain <maintainer/> element -- my script
88 will automatically add correct type="" to it afterwards.
90 I will be announcing new maintainer-needed packages after the switch,
91 so in case of disbanding a herd completely, you need to add yourself to
92 the maintainers of packages you'd like to keep manually before I do
93 that.
96 Required action from tool developers
97 ====================================
99 GLEP67 is mostly backwards compatible, so software shouldn't need being
100 updating. However, if you don't use the official DTD source
101 and validate metadata.xml files with some kind of schema, you will need
102 to update it.
104 Getting maintainers from metadata.xml will work pretty much the same.
105 After the transition, you will be able to remove the code handling
106 herds. You may also want to add some getter for the new type=""
107 attribute on <maintainer/>.
109 If you'd like to be able to expand projects into project members, you
110 will need to implement support for projects.xml and use it to map
111 type="project" maintainers. Mapping from <maintainer/> to <project/> is
112 done on matching <email/>.
114 Please note that (unlike herds.xml) projects.xml is well-defined
115 in multi-repository environment, with inheritance via masters=.
116 In other words, if you're working on metadata.xml files, don't hardcode
117 projects.xml path/URI but instead use -- in order -- the one from
118 the repository, followed by its masters.
122 Thank you for your attention. If you have any questions, please don't
123 hesitate to reply to this mail.
126 [1]:
127 [2]:
128 [3]:
129 [4]:
130 [5]:
131 [6]:
133 --
134 Best regards,
135 Michał Górny
136 <>