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