On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote:
On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote:
> On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
> > Hello,
> > I don't mean to jump in the midle here, and I am just tossing out
> > an
> > idea for consideration that doesn't address security issues pointed
> > out
> > really, but does discuss the non-responsive main maintainer.
> > I note there is a difficulty in defining the criteria for
> > determining
> > when an (apparently) inactive packager should be removed from the
> > packager group. Perhaps a different POV is required. What is the
> > problem trying to be solved? Removal of inactive packagers? Or the
> > demotion of said packager in favour for the one(s) who are
> > supporting
> > the package to be promoted to main.
>
> The former. The main issue here is a security concern: that the
> accounts of dormant packagers could be taken over and used for evil.
> So
> just shuffling the deckchairs of whether someone is a 'primary' or
> 'co'
> maintainer on a given package doesn't help. As long as they are
> allowed
> to submit official builds of the package, the problem remains
But wouldn't be possible to move their deckchair into a sandbox?
That is what we are effectively doing. By removing them from @packager,
they lose write access to packages. It is also very easy to undo.
In your approach, we'd do this package-by-package. That'd be more
complicated and harder to undo, and wouldn't really help with
the security concerns.
Zbyszek