[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-proxy-maint
Subject:    Re: [gentoo-proxy-maint] [RFC] Avoid spam
From:       NP-Hardass <NP-Hardass () gentoo ! org>
Date:       2016-06-19 22:25:30
Message-ID: 57671BDA.2090004 () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 06/19/2016 01:38 PM, Michał Górny wrote:
> On Sun, 19 Jun 2016 17:35:29 +0200
> Amy Winston <amynka@gentoo.org> wrote:
> 
>> Since the new policy causes headaches to bugzilla and spams users and
>> alias as well.
>>
>> I would like to propose more simple way. What about we have just
>> maintainer bug for every maintainer and maintainers can comment their
>> request for maintaining packages there.
>>
>> Any comments?
> 
> I'm the new guy here but I don't really understand the need for this
> bureaucracy. It all start to remind me of Sunrise -- someone trying to
> make it more bureaucratic than Gentoo itself.
Well, the whole thing was born of an almost nonexistent race condition
feared by the former lead.
> 
> I don't think we really need to expect much more action from
> proxy-maintainers than we do from Gentoo developers. After all, we're
> not giving them direct push access, and I don't think we have a very
> specific need of tracking their every action.
> 
> One thing I'd really would like to avoid is linking between maintainer
> bugs and package bugs. That indeed causes a lot of spam, not to mention
> the linking is done the wrong way around. Furthermore, it is even less
> meaningful if we assume the specific cases such as more than one
> proxied maintainer or co-maintenance with a Gentoo developer.
> 
> I can understand having a bug to request confirmation on co-maintenance
> of a package that is already maintained by a developer (or another
> proxied maintainer). However, I don't see why proxied maintainers would
> need to formally request taking over an unmaintained package. As I see
> it, a pull request / patch updating metadata.xml would be enough.
As mentioned above, the biggest concern was that if two users
simultaneously start attempting to take over a package while working
through different proxy maintainers, it could cause conflict.  In
practice, this almost never happens, and on the rare occasion that it
does, the users seem to be amenable to co-maintaining (I suspect because
they primarily want the package/updated, and don't care as much about
the logistics of how that gets done)
> 
> I understand that the maintainer bugs are supposed to be much like
> developer bugs. However, I would like to point out that developer bugs
> are mostly supposed to handle two big deals -- recruitment
> and retirement, while maintainer bugs look like they are supposed to
> track every move of the proxied maintainer.
> 
> To find packages maintained by a maintainer we can look metadata.xml
> files up. To find changes we can look git up / archives / specific
> bugs. Why do we need all the extra structure, except for the common
> idea of 'it looks more pro'?
> 
The biggest added benefit, IMO, is that it provides a means of project
members keeping track of users.  For example, if a user is negligent or
otherwise unsuited for proxy maintenance, this provides a mechanism for
detailing that, so they aren't given the opportunity to take on more
packages if they've proven themselves incapable of handling packages
already.  For that reason, I can see a benefit of keeping the maintainer
bugs, while nixing the per package request bugs.

-- 
NP-Hardass


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]