[gentoo-proxy-maint] [RFC] Avoid spam

[gentoo-proxy-maint] [RFC] Avoid spam

[Amy Winston]

[-- Attachment #1.1: Type: text/plain, Size: 320 bytes --]

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?

Thanks

Cheers,
Amy






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 899 bytes --]

On 06/19/2016 05:35 PM, Amy Winston 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 generally prefer the current way, as any discussion on maintainership
of a specific package, herunder tracking outstanding bugs that needs
fixing etc will be atomic to the package maintaining bug. If we do
everything in individual maintainer's bug we lose the possibility of
using it as a semaphore for requests on packages as well.


> Thanks
> 
> Cheers,
> Amy
> 
> 
> 
> 
> 


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

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.

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.

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'?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[Amy Winston]

[-- Attachment #1.1: Type: text/plain, Size: 2439 bytes --]


On 06/19/2016 07: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.
> 
> 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.
> 
> 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'?
> 

My idea was more like that Maintainer bug will have comments with
requests but not necessarily have links to package bugs. So we will have
Maintainer bug like Developer bug which will deal with requests for
maintaining.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1155 bytes --]

On 06/19/2016 07:38 PM, Michał Górny wrote:
> 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'?

There are also cases of maintainers changing email addresses in
bugzilla, making the metadata entry erroneous. For gentoo developers we
have centralized records in ldap, for proxied maintainers we need to
replicate some structure in bugzilla. In particular since proxied
maintainers are otherwise spread out and unstructured, we need to
enforce the structure in the project.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Sun, 19 Jun 2016 19:43:45 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 06/19/2016 07:38 PM, Michał Górny wrote:
> > 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'?  
> 
> There are also cases of maintainers changing email addresses in
> bugzilla, making the metadata entry erroneous. For gentoo developers we
> have centralized records in ldap, for proxied maintainers we need to
> replicate some structure in bugzilla. In particular since proxied
> maintainers are otherwise spread out and unstructured, we need to
> enforce the structure in the project.

Keeping track of e-mail changes is a matter of one bug, with one
comment for each e-mail change. Not 20 bugs with 80 bugspam links.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1846 bytes --]

On 06/19/2016 08:28 PM, Michał Górny wrote:
> On Sun, 19 Jun 2016 19:43:45 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> 
>> On 06/19/2016 07:38 PM, Michał Górny wrote:
>>> 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'?  
>>
>> There are also cases of maintainers changing email addresses in
>> bugzilla, making the metadata entry erroneous. For gentoo developers we
>> have centralized records in ldap, for proxied maintainers we need to
>> replicate some structure in bugzilla. In particular since proxied
>> maintainers are otherwise spread out and unstructured, we need to
>> enforce the structure in the project.
> 
> Keeping track of e-mail changes is a matter of one bug, with one
> comment for each e-mail change. Not 20 bugs with 80 bugspam links.
> 

Yeah, I mostly care about the maintainer bugs, although do believe the
appropriate way for a user to approach the proxy maint project is a
package maintenance request. If we're talking about backfilling for
active maintainers and packages I'm starting to agree that it isn't
necessary. But just filing e.g a github pull request isn't an official
channel.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-proxy-maint] [RFC] Avoid spam

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 3264 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]