1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] [RFC] Moving s outta metadata.xml, in

    From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to All on Thu Apr 7 20:50:01 2022
    Hello,

    Right now we're keeping both email addresses (obligatory) and names
    (optional) for downstream maintainers in metadata.xml. The way I see
    it, there are three problems with that:

    1. As noticed on IRC lately, a few devs haven't been listing their names
    at all, resulting in these names being missing from packages.g.o.

    2. Not all names are listed consistently. This is especially the case
    for projects. When you want to group everything by maintainer, which
    name should be used?

    3. In the end, listing the same names all over the place is a lot of redundancy.


    I'd like to propose that we deprecate <name/> for downstream
    maintainers, and instead work towards using an additional mapping from maintainer email addresses to their names.

    a. For projects, we can simply use projects.xml. We already require
    that all type="project" maintainers correspond to entries
    in projects.xml, so we should be good here.

    b. For human maintainers, I think we can use metadata/AUTHORS. This is
    pretty much killing two birds with one stone -- we could finally getting
    the file more complete, and at the same time use it to provide names for maintainers.

    While keeping names in metadata.xml has the advantage that they are
    immediately available (provided that they are actually listed there),
    I don't think this is really a show-stopper.


    WDYT?

    --
    Best regards,
    Michał Górny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matt Turner@21:1/5 to mgorny@gentoo.org on Fri Apr 8 01:10:01 2022
    On Thu, Apr 7, 2022 at 11:42 AM Michał Górny <mgorny@gentoo.org> wrote:

    Hello,

    Right now we're keeping both email addresses (obligatory) and names (optional) for downstream maintainers in metadata.xml. The way I see
    it, there are three problems with that:

    1. As noticed on IRC lately, a few devs haven't been listing their names
    at all, resulting in these names being missing from packages.g.o.

    2. Not all names are listed consistently. This is especially the case
    for projects. When you want to group everything by maintainer, which
    name should be used?

    3. In the end, listing the same names all over the place is a lot of redundancy.


    I'd like to propose that we deprecate <name/> for downstream
    maintainers, and instead work towards using an additional mapping from maintainer email addresses to their names.

    a. For projects, we can simply use projects.xml. We already require
    that all type="project" maintainers correspond to entries
    in projects.xml, so we should be good here.

    b. For human maintainers, I think we can use metadata/AUTHORS. This is pretty much killing two birds with one stone -- we could finally getting
    the file more complete, and at the same time use it to provide names for maintainers.

    While keeping names in metadata.xml has the advantage that they are immediately available (provided that they are actually listed there),
    I don't think this is really a show-stopper.

    Sounds like a good plan to me.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to All on Fri Apr 8 01:30:01 2022
    On 8 Apr 2022, at 00:07, Matt Turner <mattst88@gentoo.org> wrote:

    On Thu, Apr 7, 2022 at 11:42 AM Michał Górny <mgorny@gentoo.org> wrote:

    Hello,

    Right now we're keeping both email addresses (obligatory) and names
    (optional) for downstream maintainers in metadata.xml. The way I see
    it, there are three problems with that:

    1. As noticed on IRC lately, a few devs haven't been listing their names
    at all, resulting in these names being missing from packages.g.o.

    2. Not all names are listed consistently. This is especially the case
    for projects. When you want to group everything by maintainer, which
    name should be used?

    3. In the end, listing the same names all over the place is a lot of
    redundancy.


    I'd like to propose that we deprecate <name/> for downstream
    maintainers, and instead work towards using an additional mapping from
    maintainer email addresses to their names.

    a. For projects, we can simply use projects.xml. We already require
    that all type="project" maintainers correspond to entries
    in projects.xml, so we should be good here.

    b. For human maintainers, I think we can use metadata/AUTHORS. This is
    pretty much killing two birds with one stone -- we could finally getting
    the file more complete, and at the same time use it to provide names for
    maintainers.

    While keeping names in metadata.xml has the advantage that they are
    immediately available (provided that they are actually listed there),
    I don't think this is really a show-stopper.

    Sounds like a good plan to me.

    Yep. It also has a nice consequence of allowing AUTHORS to be used as a mailmap for git (although git doesn't respect symlinks for mailmap, so we'd need to tell
    people to set it with the config option, but still.)

    The main value for me is in making AUTHORS more useful. If it has to exist,
    we should use it properly.

    But I love a bit of deduplication too.

    Best,
    sam

    -----BEGIN PGP SIGNATURE-----

    iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmJPcrNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDubVQgAghQ2Ob9prWOHi6fmOkyU91kTojZNbBsjxlUHD2zTJfMbQcJmM7uy4Iif 8nSv3JH4Wb5v97JErO+g6CHTEcVHvo6Sz0D/cMLPOCit6WJRxEmaxJYsgnl67dBN vnliQzVqu+epfQmiEoxUNqlYDAI/skAobGwCKUUaPIFkj/0zm95Tmf/t1N1IbUkP 8U1pSf564JTa23yfoa4rDzIjEFjH7XQqBG8kn/7VZ2FYjQa1Ofkgcxd/zsimsLjD VEciw92mULJmpeaD2jKLnRW0zsf5it++mxb9jXLrR8YWW8MskWePUCCSA2/wbIqC KuUwxuMfFePBFy5GP8a+gFMdJeyJ6w==
    =aWWU
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)