Quoting Ole Streicher (2021-11-07 11:18:34)

during the discussion of the new Debian Math Blend/Team in the debian-science mailing list, some people expressed their fear that
many packages cannot be simply maintained because they belong to a
different team.

Specifically, we have teams within (at least) two dimenion:

1. Language (or so) oriented teams, like for Python, Java etc.
2. Topical (or Blends) oriented teams, like Astro, Science, Med

An astronomy related Python package would usually be maintained by the Astronomy team. This has the disadvantage, that the Python team cannot
just "team upload" this package; which makes bulk updated more
complicated than necessary.

One solution here could be to recognize multiple teams: the "primary
one" (by the maintainer's selection) goes into the "Maintainer:" field
in d/control, and all secondary would go into the "Uploaders:" field.
This would imply that the package is conform to all team policies,
except for the salsa location of the package (i.e. a package that has
the Debian Astro Team as primary team would live in the salsa.d.o/debian-astro/team/).

For team related tests/uploads, this would probably require to update
the scripts to find all team packages, and adjust the permissions (by package) on Salsa to allow pushes from other teams.

On the other hand, it would significantly improve the maintainance for
a number of packages.

Salsa access rights include the option to grant access to Debian
developers at large, which can be used to permit upload rights for
secondary teams (as upload generally requires Debian membership anyway).

At https://tracker.debian.org/teams/ arbitrary sets of packages can be monitored together, with email subscriptions to changes, which can be
used as aid for "secondary" teams.

If lintian warns about uploads about team uploads made by the "wrong"
team then I would simply ignore that.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============H78783098434432874=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGHsC0ACgkQLHwxRsGg ASEUdA/8CSTdseojdNnrubS0V/1sp1PPb76NftHx3ikAa2+kVtpi+P6hQNzysdHf WPNLe9HmWJrpRVD9CrdEEdt/Xnv0qk3BekYKm1gBdHj5tN5Qyd8DRjvikLuKE/KW 2GM5Gvh7RERGEqHqHhBbK+EkZ5/KbfOJuTMguWxEVaPawYwinnjpoeHQsuyvOscQ nEsKiuPlEvCcWKoPnAh0xy7chydOwzEwWPt5qckGbHKc1yf+jhiq+le9D4+/Cctt 9gDFTABUMchEibVzyouboelkdvqhbdf5xJFw76Ef8mmNg6CyLgvUc8k0weNFy6KE SOMQTDJMlMv9ySn0o+H+cJ5grdSaAOJj4GZRnWzULrlrS4RXjF1bAc7xqv2zdn1P Nwd//XUMAd5nOaBkbJoOF9DBh+rraitjiieD8pxMoCskYUOfVFP/gphod6aN4k8N Hq4M2yDinxiT2PWjtdChsSF8+ofpyimJXgvLhjxC7Qm7nqadQW6dFVTGrodLanpm LVh2mjo+ZgYP8MBcu

Dear fellow developers,

during the discussion of the new Debian Math Blend/Team in the
debian-science mailing list, some people expressed their fear that many packages cannot be simply maintained because they belong to a different
team.

Specifically, we have teams within (at least) two dimenion:

1. Language (or so) oriented teams, like for Python, Java etc.
2. Topical (or Blends) oriented teams, like Astro, Science, Med

An astronomy related Python package would usually be maintained by the Astronomy team. This has the disadvantage, that the Python team cannot
just "team upload" this package; which makes bulk updated more
complicated than necessary.

One solution here could be to recognize multiple teams: the "primary
one" (by the maintainer's selection) goes into the "Maintainer:" field
in d/control, and all secondary would go into the "Uploaders:"
field. This would imply that the package is conform to all team
policies, except for the salsa location of the package (i.e. a package
that has the Debian Astro Team as primary team would live in the salsa.d.o/debian-astro/team/).

For team related tests/uploads, this would probably require to update
the scripts to find all team packages, and adjust the permissions (by
package) on Salsa to allow pushes from other teams.

On the other hand, it would significantly improve the maintainance for a
number of packages.

Best regards

Ole

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

On 16310 March 1977, Jonas Smedegaard wrote:

Salsa access rights include the option to grant access to Debian
developers at large, which can be used to permit upload rights for
secondary teams (as upload generally requires Debian membership
anyway).

Salsa lets one team grant rights to another team. (Group in salsa).
Instead of inviting a member to your group, select the invite group part
and add the team. It can even do "subgroups", so say if the python
team would have different membership for python modules and python
application, one could select to only allow the modules people access.

May be a better selection than adding "all of the DDs".

--
bye, Joerg

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

On Sun, Nov 7, 2021 at 5:36 AM Ole Streicher <[email protected]> wrote:

One solution here could be to recognize multiple teams: the "primary
one" (by the maintainer's selection) goes into the "Maintainer:" field
in d/control, and all secondary would go into the "Uploaders:"
field. This would imply that the package is conform to all team
policies, except for the salsa location of the package (i.e. a package
that has the Debian Astro Team as primary team would live in the salsa.d.o/debian-astro/team/).

The GNOME and Accessibility Teams co-maintain a few packages. They are
hosted on the GNOME team's Salsa. I believe most have the Maintainer
set to the Accessibility Team (like orca) but atkmm1.6 has the
Maintainer set to the GNOME team.

It works well because the GNOME Team has a lot more packaging style
tweaks than the Accessibility team so it's easy for these packages to
follow GNOME style without conflicting with a different team's style.

Thanks,
Jeremy Bicha

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