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/>
pgpdO8RDlcmiP.pgp
Description: OpenPGP digital signature
