{"id":400,"date":"2016-01-16T11:31:03","date_gmt":"2016-01-16T10:31:03","guid":{"rendered":"https:\/\/blogs.gentoo.org\/mgorny\/?p=400"},"modified":"2016-01-16T13:49:54","modified_gmt":"2016-01-16T12:49:54","slug":"glep67-or-how-packages-are-going-to-be-maintained","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2016\/01\/16\/glep67-or-how-packages-are-going-to-be-maintained\/","title":{"rendered":"GLEP67, or how packages are going to be maintained"},"content":{"rendered":"

The\u00a0way packages are maintained in\u00a0Gentoo have been evolving for quite some time already. So far all of\u00a0that has been happening on top of\u00a0old file formats which slowly started to diverge from the\u00a0needs of\u00a0Gentoo developers, and\u00a0become partially broken. The\u00a0concept of herds has become blurry, with confusion in\u00a0definition between different developers and\u00a0partial assumption about their deprecation. Maintenance of\u00a0herd by\u00a0project has been broken by moving projects to the\u00a0Wiki. Some projects have stopped using herds, others have been declaring them in\u00a0metadata.xml<\/kbd> in\u00a0different ways.<\/p>\n

The\u00a0problem has finally reached the\u00a0Gentoo Council and\u00a0has been discussed on\u00a02015-10-25 meeting (note: no summary still\u2026). The\u00a0Council attempted to address different problems by votes, and\u00a0create a\u00a0new solution by\u00a0combining the\u00a0results of votes. However, finally it decided that it is not possible to create a\u00a0good specification this way. Instead, the\u00a0meeting has brought two major points. Firstly, herds are definitely deprecated. Secondly, someone needs to provide a\u00a0complete, consistent replacement in\u00a0GLEP form.<\/p>\n

This is how GLEP 67<\/a> came to be. It was based on\u00a0results of\u00a0previous discussion, Council votes and\u00a0thorough analysis of\u00a0different problems. It provides a\u00a0complete, consistent system for maintaining packages and\u00a0expressing the\u00a0maintenance information. It has been approved by\u00a0the\u00a0Council on 2016-01-10<\/a>, with two week deadline on\u00a0preparing to the\u00a0switch.<\/p>\n

Therefore, on 2016-01-24 Gentoo is going to switch to the\u00a0new maintenance structure described in\u00a0GLEP 67 completely. The\u00a0announcement with transition details<\/a> has been sent already. Instead, I’d like to focus on describing how things are going to work starting from the\u00a0day GLEP 67 becomes implemented.<\/p>\n

<\/p>\n

Who is going to maintain packages?<\/h2>\n

Before getting into technical details, GLEP 67 starts by limiting possible package maintainer entries. Until now, metadata files were allowed to list practically any e-mail addresses for package maintainers. From now on, only real people (either developers or\u00a0proxied maintainers) and\u00a0projects (meeting the\u00a0requirements of\u00a0GLEP 39<\/a>, in\u00a0particular having a\u00a0Wiki page) are allowed to be\u00a0maintainers. All maintainers are identified by\u00a0e-mail addresses which are required to be unique (i.e. sharing the\u00a0same address between multiple projects is forbidden) and\u00a0registered on\u00a0bugs.g.o.<\/p>\n

This supports the\u00a0two major goals behind maintainer specifications: bug assignment and\u00a0responsibility assignment. The\u00a0former is rather obvious \u2014 Bugzilla is the\u00a0most reliable communication platform for both Gentoo developers and\u00a0users. Therefore, it is important that the\u00a0bugs can be assigned to appropriate entities without any issues. The\u00a0latter aims to address the\u00a0problem of unclear \u2018ownership\u2019 of some packages, and\u00a0packages maintained by \u2018dead\u2019 e-mail aliases.<\/p>\n

In\u00a0other words, from now on we require that for every maintained package in\u00a0Gentoo, we need to be able to obtain a\u00a0complete, clear list of\u00a0people maintaining it (directly and\u00a0via projects). We no longer accept \u2018dumb\u2019 e-mail aliases that make it impossible to distinguish real maintainers from people who are simply following bugs. This gives three important advantages:<\/p>\n

    \n
  1. we can actually ping the\u00a0correct people on\u00a0IRC without having to go through hoops,<\/li>\n
  2. we can determine whether a\u00a0package is actually maintained by\u00a0someone, rather than assigned to an\u00a0alias from which nobody reads bug mail anymore,<\/li>\n
  3. we can clearly determine who is responsible for a\u00a0package and\u00a0who is the\u00a0appropriate person to acknowledge changes.<\/li>\n<\/ol>\n

    Changes for maintainer-needed packages<\/h2>\n

    The\u00a0new requirements brought a\u00a0new issue: maintainer-needed@g.o. The\u00a0specific use of\u00a0this e-mail alias did not really seem to suit a\u00a0project. Creating a\u00a0\u2018maintainer-needed project\u2019 would either imply creating a\u00a0dead entity or\u00a0assigning actual maintainers to supposedly-unmaintained packages. On the\u00a0other hand, I did not really want to introduce special cases in\u00a0the\u00a0specification.<\/p>\n

    Instead, I have decided that the\u00a0best way forward is to remove it. In\u00a0other words, unmaintained packages now explicitly list no maintainers. The\u00a0assignment to maintainer-needed@g.o will be done implicitly, and\u00a0is a\u00a0rule specific to the\u00a0Gentoo repository. Other repositories may use different policies for packages with no\u00a0explicit maintainers (like assigning to the\u00a0repository owner).<\/p>\n

    The metadata.xml and projects.xml files<\/h2>\n

    The\u00a0changes to metadata.xml<\/kbd> are really minimal, and\u00a0backwards compatible. The\u00a0<herd\/><\/code> element is no longer used, and\u00a0will be\u00a0prohibited. Instead, <maintainer\/><\/code> elements are going to be used for all kinds of\u00a0maintainers. There are no incompatible changes in\u00a0those elements, therefore existing tools will not be\u00a0broken.<\/p>\n

    The\u00a0<maintainer\/><\/code> element gets a\u00a0new obligatory<\/em> type<\/code> attribute that needs to either be person<\/code> or\u00a0project<\/code>. The\u00a0latter value may cause tools to look the\u00a0project up (by\u00a0e-mail) in\u00a0projects.xml<\/kbd>.<\/p>\n

    The\u00a0projects.xml<\/kbd> file (unlike past herds.xml<\/kbd>) is clearly defined in\u00a0the\u00a0repository scope. In\u00a0particular, the\u00a0tools must not assume it always comes out of Gentoo repository. Other repositories are allowed to define their own projects (though overriding projects is not allowed), and\u00a0project lookup needs to respect masters=<\/code> setting in\u00a0repositories.<\/p>\n

    For\u00a0the\u00a0Gentoo repository, projects.xml<\/kbd> is generated automatically from the\u00a0Wiki project pages, and\u00a0distributed both via api.gentoo.org and\u00a0via the\u00a0usual repository distribution means (the\u00a0rsync and\u00a0git mirrors).<\/p>\n

    Summary<\/h2>\n

    A\u00a0quick summary for Gentoo developers of how things look like with GLEP 67:<\/p>\n

      \n
    1. Only people and\u00a0projects can maintain packages. If\u00a0you want to maintain packages in an\u00a0organized group, you have to create a\u00a0project \u2014 with Wiki page, unique e-mail address and\u00a0bugs.g.o account.<\/li>\n
    2. Only the\u00a0explicitly listed project members (and\u00a0subproject members whenever member inheritance is enabled) are considered maintainers of the\u00a0package. Other people subscribing the\u00a0e-mail alias are not counted.<\/li>\n
    3. Packages with no maintainers have no <maintainer\/><\/code> elements. The\u00a0bugs are still implicitly assigned to maintainer-needed@g.o<\/kbd> but this e-mail alias is no longer used in\u00a0metadata.xml<\/kbd>.<\/li>\n
    4. <herd\/><\/code> elements are no longer used, <maintainer\/><\/code>s are used instead.<\/li>\n
    5. <maintainer\/><\/code> requires a\u00a0new type<\/code> attribute that takes either person<\/code> or\u00a0project<\/code> value.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

      The\u00a0way packages are maintained in\u00a0Gentoo have been evolving for quite some time already. So far all of\u00a0that has been happening on top of\u00a0old file formats which slowly started to diverge from the\u00a0needs of\u00a0Gentoo developers, and\u00a0become partially broken. The\u00a0concept of herds has become blurry, with confusion in\u00a0definition between different developers and\u00a0partial assumption about their deprecation. Maintenance … Continue reading “GLEP67, or how packages are going to be maintained”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/400"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=400"}],"version-history":[{"count":10,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/400\/revisions"}],"predecessor-version":[{"id":411,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/400\/revisions\/411"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=400"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=400"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=400"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}