Automatic commit request approvial in pkgdb?
On Fri, 20 Jan 2012 15:38:47 -0700, KF (Kevin) wrote:
On Tue, 17 Jan 2012 02:20:15 +0100
Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > We talked about, but never finished implementing a timeout on acl
> > requests.
> >
> > The way this would work is that maintainer would have some time.. 3
> > weeks or something to reject a acl request. If they did not do so,
> > pkgdb would automatically approve it at the end of the time.
> > This would help in cases where the maintainer is overloaded or not
> > paying attention.
>
> The question is of course why we need to allow the maintainer to
> reject comaintainership in the first place.
Sure. In an ideal world we never would.
In the real world it might be that someone is a new maintainer and
wanting to work on a package that is very complex or sensitive without
much background, or someone who the current maintainers know they
differ on philosophy or something that would make working together
difficult, or a maintainer who doesn't get along with upstream and
would cause undue friction, or a maintainer who doesn't communicate
with existing maintainers well, etc.
There would be extended rules about who would be allowed to modify a
package, and in which ways a package may be modified.
It would be rather disappointing, if the infamous "hostile takeover"
scenario for packages were the primary reason for not offering automatic
commit request approval in pkgdb. How often would it happen that one
packager refuses to apply a patch/upgrade and another one tries to force
changes upon everyone else? And if that happened, it would be reversible.
Abuse could lead to appropriate consequences.
I'm more concerned about some accounts acquiring commit access to a
growing number of packages, pretending that those "have maintainers",
but without handling bug reports and other maintenance tasks. Then, if the
original package submitter leaves silently (which happens regularly
apparently), the package doesn't become an orphan.
How often does it happen that pkgdb requests are not answered? How often
are pkgdb commit acl requests made because a current maintainer does not
respond elsewhere either? (and the non-responsive maintainer procedure
ought to be started)
It could also be considered a security risk, if an arbitrary member of the
packager group may gain [temporary!] write-access to arbitrary packages.
That may become more of a risk, if the number of semi-orphaned/unmaintained
packages in the collection increases, and not just pkgdb requests aren't
seen but git commits aren't observed by anyone either.