1 |
Hello, everyone. |
2 |
|
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]). |
6 |
|
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. |
11 |
|
12 |
I will be explaining GLEP67 in detail sometime this week. For now, I'd |
13 |
like to focus on necessary transition notes. |
14 |
|
15 |
|
16 |
Implementation progress |
17 |
======================= |
18 |
|
19 |
I. Most of herds have been handled already (thanks, kensington!). |
20 |
|
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). |
23 |
|
24 |
III. projects.xml should already be generated from wiki and distributed |
25 |
via rsync & git mirror. |
26 |
|
27 |
IV. willikins was given new !proj command to expand projects. I'm going |
28 |
to start working on !meta today. |
29 |
|
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. |
33 |
|
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. |
37 |
|
38 |
VII. All migration scripts are ready, and test conversions are available |
39 |
for review [5]. I'm updating them every few days. |
40 |
|
41 |
|
42 |
|
43 |
Required action from Gentoo developers |
44 |
====================================== |
45 |
|
46 |
In the following two weeks, developers have to ensure that: |
47 |
|
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. |
53 |
|
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 @gentoo.org, so ask Infra for it. |
57 |
|
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. |
61 |
|
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. |
66 |
|
67 |
|
68 |
Now, my automated conversion script gives three possibilities for each |
69 |
herd: |
70 |
|
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. |
75 |
|
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. |
79 |
|
80 |
c. Disbanding with no replacement -- in this case, <herd/> will be |
81 |
removed with no replacement. Some packages will become |
82 |
maintainer-needed. |
83 |
|
84 |
|
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. |
89 |
|
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. |
94 |
|
95 |
|
96 |
Required action from tool developers |
97 |
==================================== |
98 |
|
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. |
103 |
|
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/>. |
108 |
|
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/>. |
113 |
|
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. |
119 |
|
120 |
|
121 |
|
122 |
Thank you for your attention. If you have any questions, please don't |
123 |
hesitate to reply to this mail. |
124 |
|
125 |
|
126 |
[1]:https://projects.gentoo.org/council/meeting-logs/20160110-log.txt |
127 |
[2]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67 |
128 |
[3]:https://wiki.gentoo.org/wiki/GLEP:67 |
129 |
[4]:https://bugs.gentoo.org/show_bug.cgi?id=glep67-tracker |
130 |
[5]:https://github.com/gentoo/gentoo/pull/559 |
131 |
[6]:https://wiki.gentoo.org/wiki/Project:Metastructure/Herd_to_project_mapping |
132 |
|
133 |
-- |
134 |
Best regards, |
135 |
Michał Górny |
136 |
<http://dev.gentoo.org/~mgorny/> |