| 1 |
On 06/19/2016 07: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 |
> |
| 18 |
> I don't think we really need to expect much more action from |
| 19 |
> proxy-maintainers than we do from Gentoo developers. After all, we're |
| 20 |
> not giving them direct push access, and I don't think we have a very |
| 21 |
> specific need of tracking their every action. |
| 22 |
> |
| 23 |
> One thing I'd really would like to avoid is linking between maintainer |
| 24 |
> bugs and package bugs. That indeed causes a lot of spam, not to mention |
| 25 |
> the linking is done the wrong way around. Furthermore, it is even less |
| 26 |
> meaningful if we assume the specific cases such as more than one |
| 27 |
> proxied maintainer or co-maintenance with a Gentoo developer. |
| 28 |
> |
| 29 |
> I can understand having a bug to request confirmation on co-maintenance |
| 30 |
> of a package that is already maintained by a developer (or another |
| 31 |
> proxied maintainer). However, I don't see why proxied maintainers would |
| 32 |
> need to formally request taking over an unmaintained package. As I see |
| 33 |
> it, a pull request / patch updating metadata.xml would be enough. |
| 34 |
> |
| 35 |
> I understand that the maintainer bugs are supposed to be much like |
| 36 |
> developer bugs. However, I would like to point out that developer bugs |
| 37 |
> are mostly supposed to handle two big deals -- recruitment |
| 38 |
> and retirement, while maintainer bugs look like they are supposed to |
| 39 |
> track every move of the proxied maintainer. |
| 40 |
> |
| 41 |
> To find packages maintained by a maintainer we can look metadata.xml |
| 42 |
> files up. To find changes we can look git up / archives / specific |
| 43 |
> bugs. Why do we need all the extra structure, except for the common |
| 44 |
> idea of 'it looks more pro'? |
| 45 |
> |
| 46 |
|
| 47 |
My idea was more like that Maintainer bug will have comments with |
| 48 |
requests but not necessarily have links to package bugs. So we will have |
| 49 |
Maintainer bug like Developer bug which will deal with requests for |
| 50 |
maintaining. |
Archives