[gentoo-dev] GLEP67 officially approved with 2-week deadline

[gentoo-dev] GLEP67 officially approved with 2-week deadline

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5319 bytes --]

Hello, everyone.

With a little delay, I'd like to announce that the 2016-01-10 Council
meeting (log [1], no summary yet) has resulted in the current
wording of GLEP67 being approved ([2], not yet moved to [3]).

Considering the progress so far (tracked in [4]), the Council has set
the deadline for herd status updates to 2 weeks from the meeting
(2016-01-24). At this point, all metadata.xml files will be updated
automatically and their conformance to GLEP67 will become obligatory.

I will be explaining GLEP67 in detail sometime this week. For now, I'd
like to focus on necessary transition notes.


Implementation progress
=======================

I. Most of herds have been handled already (thanks, kensington!).

II. I've opened bugs for all offending projects and herds (list may be
outdated, I'd be doing a second check soon).

III. projects.xml should already be generated from wiki and distributed
via rsync & git mirror.

IV. willikins was given new !proj command to expand projects. I'm going
to start working on !meta today.

V. I've got necessary metadata.dtd updates on a branch. After merging
it to master, the new version will start being distributed and enforced
by repoman.

VI. I've sent small Portage update to the ml. However, it would be nice
if someone wrote full set of <maintainer/> checks for repoman, including
checking if type="project" maintainers are in projects.xml.

VII. All migration scripts are ready, and test conversions are available
for review [5]. I'm updating them every few days.



Required action from Gentoo developers
======================================

In the following two weeks, developers have to ensure that:

1. all project pages list unique, dedicated e-mail addresses for
the projects, or no addresses at all. Sharing the same address between
multiple projects is forbidden, as is reusing developer's e-mail
address for a project. If necessary, ask Infra to create an alias for
you.

2. If a project wishes to maintain any packages, its e-mail address
needs to be registered on Bugzilla. Only Infra can create Bugzilla
accounts for @gentoo.org, so ask Infra for it.

3. The fate of the remaining herds needs to be decided by their
maintainers and listed on the mapping page [6]. We will be using this
page when doing the automated metadata updates.

4. There can not be any 'rogue' maintainers left. In other words, all
packages need to be maintained by explicit people (developers or
proxied maintainers), or explicit projects. No 'dumb' aliases are
allowed.


Now, my automated conversion script gives three possibilities for each
herd:

a. mapping to a single project -- in this case all <herd/> occurrences
will be replaced by the matching project. Multiple herds can be mapped
into one project but we don't support splitting herd into more
projects.

b. Disbanding and replacing with maintainers -- in this case all
current herd maintainers (taken from herds.xml) will be put into
metadata.xml directly.

c. Disbanding with no replacement -- in this case, <herd/> will be
removed with no replacement. Some packages will become
maintainer-needed.


Whenever this is not sufficient for your herd, please update
the metadata beforehand, if possible. Don't create new herds, though.
If you need a new project, use plain <maintainer/> element -- my script
will automatically add correct type="" to it afterwards.

I will be announcing new maintainer-needed packages after the switch,
so in case of disbanding a herd completely, you need to add yourself to
the maintainers of packages you'd like to keep manually before I do
that.


Required action from tool developers
====================================

GLEP67 is mostly backwards compatible, so software shouldn't need being
updating. However, if you don't use the official DTD source
and validate metadata.xml files with some kind of schema, you will need
to update it.

Getting maintainers from metadata.xml will work pretty much the same.
After the transition, you will be able to remove the code handling
herds. You may also want to add some getter for the new type=""
attribute on <maintainer/>.

If you'd like to be able to expand projects into project members, you
will need to implement support for projects.xml and use it to map
type="project" maintainers. Mapping from <maintainer/> to <project/> is
done on matching <email/>.

Please note that (unlike herds.xml) projects.xml is well-defined
in multi-repository environment, with inheritance via masters=.
In other words, if you're working on metadata.xml files, don't hardcode
projects.xml path/URI but instead use -- in order -- the one from
the repository, followed by its masters.



Thank you for your attention. If you have any questions, please don't
hesitate to reply to this mail.


[1]:https://projects.gentoo.org/council/meeting-logs/20160110-log.txt
[2]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67
[3]:https://wiki.gentoo.org/wiki/GLEP:67
[4]:https://bugs.gentoo.org/show_bug.cgi?id=glep67-tracker
[5]:https://github.com/gentoo/gentoo/pull/559
[6]:https://wiki.gentoo.org/wiki/Project:Metastructure/Herd_to_project_mapping

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]