Re: Multiple teams maintaining one package (proposal)

[Jeremy Bicha]

On Sun, Nov 7, 2021 at 5:36 AM Ole Streicher  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

Re: Multiple teams maintaining one package (proposal)

[Joerg Jaspert]

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

Re: Multiple teams maintaining one package (proposal)

[Jonas Smedegaard]

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

signature.asc
Description: signature