* Re: [gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs
2017-07-17 18:31 [gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs Michał Górny
@ 2017-07-18 8:11 ` Sven Eden
2017-07-18 10:41 ` Sam Jorna
1 sibling, 0 replies; 3+ messages in thread
From: Sven Eden @ 2017-07-18 8:11 UTC (permalink / raw
To: gentoo-proxy-maint
[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]
Hi Michał,
thank you for your E-Mail, this was a very interesting read!
Am Montag, 17. Juli 2017, 20:31:13 CEST schrieb Michał Górny:
> Hi, everyone.
>
> TL;DR: let's kill obligatory "maintainership" bugs. Maintainer bugs are
> enough, and floods of bugs don't help neither maintainers nor
> developers.
The way you describe it, the status quo sounds horrible to me. Much ado about
nothing, more or less.
> [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_a
> nd_Maintainership_Requests
The whole page sounds sane. Sane in a "Let's-Do-It-Right"-way. But it looks
like following this guide word-by-word will not only produce a lot of work,
but also a lot of noise. And only a couple of packages later, that list e-
mails get send to can grow very long indeed.
Reading this page helped me a lot to understand your point.
> [2]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Managing_Requests
This is the first time I ever heard of "Maintainer: ${NAME} (${NICK})" bugs.
And the whole description does not make much sense to me. Both git and
metadata.xml should be more than enough, shouldn't they? Why should I want a
personal (but public) bug to track what I am maintaining?
> [3]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide
I think that this page covers the workflow I am used pretty well. But I'd like
to see a bit more guiidance for PRs.
You mention them, and the "Commit Policy for users" section is *highly*
valuable, but a few lines of guidance about what to squash and how to generate
which amount of commits in a PR would be great.
(Okay, thanks to the PR reviews, any proxied maintainer would learn by doing
anyway, but it's people like you having to request changes all over again. ;-)
)
At the end of the day I am very fond of your update proposal. :-)
Cheers
Sven
--
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs
2017-07-17 18:31 [gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs Michał Górny
2017-07-18 8:11 ` Sven Eden
@ 2017-07-18 10:41 ` Sam Jorna
1 sibling, 0 replies; 3+ messages in thread
From: Sam Jorna @ 2017-07-18 10:41 UTC (permalink / raw
To: gentoo-proxy-maint
[-- Attachment #1.1: Type: text/plain, Size: 4378 bytes --]
On 18/07/17 04:31, Michał Górny wrote:
> Hi, everyone.
>
> TL;DR: let's kill obligatory "maintainership" bugs. Maintainer bugs are
> enough, and floods of bugs don't help neither maintainers nor
> developers.
>
>
> We seem to have terribly convoluted policies and guides regarding bugs
> right now [1,2]. Besides the guides being insanely detailed, the policy
> itself is just wrong and creates a lot of meaningless bureaucracy that
> only wastes time of both the developers and proxied maintainers.
The current policies were written at a time when some specific issues
needed to be managed and, as the first attempt at writing such policies,
needed to be reasonably explicit. They also went through the regular RFC
process through the project without objection.
That being said, they were written with both those points in mind - I
welcome improvements.
> So, let's say a user wants to take a package along with its
> dependencies. Next thing I know, I'm spammed with 15 bugs, one for every
> package. Not that they're of any value to me since I won't be tracking
> progress for every single one of those packages separately, or that I
> need to track the progress via the bug at all.
>
> Things get even worse when developers try to follow policies to
> the word, and start linking a lot of random bugs together, creating 50
> useless mails for the sake of pretty, meaningless structure.
>
> Not to mention the creeps I get every time I see another person says
> 'maintainership'. Protip: such a word does not exist. it's
> 'maintenance'.
Point out silly things, win silly prizes.
It actually started off as a placeholder as I couldn't think of a more
"real" word with a clear enough distinction between the act of package
maintenance and the state of being a maintainer of a given package.
No-one objected, and here we are. :)
> Enough bickering. Now, what I propose.
awww...
> First of all, we kill per-package bugs altogether. We optionally allow
> a single 'maintenance request' bug per request, if we need to gather
> developer's permission or otherwise have a reason to do some
> bureaucracy.
>
> If such a bug is used, the user can list the packages he wants to take
> inside, and we can reply with any requests we might have. We *do not*
> link any bugs to avoid creating noise.
>
> Otherwise, we can just handle maintenance requests implicitly -- on top
> of pull requests or bugs where the user submits patches.
This sounds good to me, however such a simplistic approach doesn't
handle one of the (admittedly corner-case) issues the current process
does - specifically, two users requesting maintenance (the real-word
version) of the same package from two developers, each unaware of the other.
There haven't been many cases of this that I can think of, and it may be
something to be addressed if and when it happens, but I wanted to point
it out.
> Secondly, we keep maintainer bugs for the purpose of tracking e-mail
> address changes and only that. We do not link them, we do not list
> packages in them -- just e-mail addresses. If someone wants to check
> what the user maintains, he can do a trivial grep on metadata.xml
> instead of trying to process all that inconsistent comment noise.
Should existing linked bugs be unlinked (creating one mass-spam) or deal
with them as they come?
> We do not require proxied maintainers to create those bugs up front.
> Instead, we open them with a short explanation after merging the first
> relevant commit
It might be worthwhile doing this before the first commit (at least, if
you haven't worked with the contributor before) - it's a reminder to
check if they already maintain something in the tree.
Somewhat tangential to this, would there be benefit to offering a common
list of resources to new maintainers? Currently reference pages are
largely unknown because there's no clear index of them - most of the
time people only find out about something when someone happens to link
to a reference on it.
> Thirdly, we kill those two horrible guides. Instead, I'll add a short
> explanation of the two points above to the regular guide at [3].
I'd like to see what I'm buying first, but based on the above it sounds
good to me.
--
Sam Jorna (wraeth) <wraeth@gentoo.org>
GnuPG Key: D6180C26
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread