Re: [gentoo-proxy-maint] [RFC] New doc & policy

[Sam Jorna]

On 20/07/17 18:02, Michał Górny wrote:
> * ability to request keywording on additional architectures (but note
> that most of arch teams are against proactive keywording) and to request
> stabilization;

Stabilisation requests can also be filed by users per [1] without being
the maintainer.

> * full decision power — we restrict the right to reject or override your
> decisions at the review level,

s:restrict:reserve:

> * ensure that the package follows the best practices (preferably of our
> own accord),

I'm not sure what this wording is supposed to mean.

> ==How to become a proxied maintainer==
> There is no special process for becoming a proxied maintainer — you
> become one when your first commit is merged.

Perhaps just "You are assigned as the maintainer when your first commit
is merged". Might also be worth suggesting the first commit be to update
metadata.xml.

> Our team will review the submitted files and help you bring them to the
> top quality. Once the package is ready, we will merge it and close the
> relevant bugs (if there are any).

The bugs should probably be assigned to the maintainer for them to close
(if suitable) or otherwise deal with, as described below.

> * If the package has an existing maintainer, he will be asked to ACK
> your changes and approve your request. Gentoo developers can reject a
> proxied maintainer if they have a good reason to do so.

Other Gentoo devs can also proxy commits in-place of Proxy Maintainers,
as in proxy-maint is not included at all, at the other developers
discretion.

> ===GitHub pull requests===
> The preferred way of submitting your contributions is through [https://g
> ithub.com/gentoo/gentoo/pulls pull requests on our GitHub repository].
> At the moment, it gives the best response time, and the widest audience
> for reviews.

Unless we're actively pushing for Github over other methods, I'd avoid
"preferred"; but I'm not overly fussed either way.

> It is recommended that you try to keep the same commit structure as
> you'd use when committing straight to Gentoo as a developer, and follow
> the best git practices (atomic changes, proper commit messages). For

A link to [2] or [3] may be useful here (or, at least, /somewhere/).

> The alternative to GitHub is to use the [https://archives.gentoo.org/gen

s:The:One of the:

> You need to explicitly use <kbd>repoman full -e y</kbd> to verify the
> experimental profiles.

What about developer profiles (`repoman full -d`) and checking metadata
(`repoman full -x`)?

> ===Keywording & stabilization===
> As a proxied maintainer, you can request [https://devmanual.gentoo.org/k
> eywording/index.html keywording and stabilization] of your packages.
> However, all those requests need to be approved by proxy-maint team
> member (or a regular developer co-maintainer) first.

As mentioned previously, others can request stabilisation as well.

> ===The maintainer bug===
> Since proxied maintainers do not have full access to the Gentoo
> developer services, the proxy-maint project is using ''maintainer bugs''
> to track status of the proxied maintainers.
>
> Once your first contribution is merged, we will create the maintainer
> bug for you. We will note your name and/or nickname (for communication
> purposes) and your e-mail address used in metadata.xml. We will
> afterwards use the bug to track the changes in your e-mail address and
> your contributor status.
>
> If you ever change your Bugzilla e-mail address, please remember to
> submit an update to your package {{Path|metadata.xml}} files. We will
> also note the new e-mail address on the maintainer bug.

This implies maintainer address and bugzilla address may be different,
which will annoy bug wranglers to no end.

> proxy-maint project), please send an email to [[mailto:gentoo-dev@lists.
> gentoo.org gentoo-dev@l.g.o] mailing list titled 'Packages up

Something is off with the email syntax here - it's not rendering
properly. Also, CC proxy-maint@lists.g.o?

It might also be good to finish with a list of links to resources, such
as the references below, devmanual, and maybe PMS.

Otherwise, comments aside, looks good to me - certainly less cumbersome
than the beast I created.

Good work, and thanks.

[1] https://wiki.gentoo.org/wiki/Stable_request
[2] https://wiki.gentoo.org/wiki/Gentoo_git_workflow
[3] https://wiki.gentoo.org/wiki/Gentoo_GitHub

-- 
Sam Jorna (wraeth) <wraeth@g.o>
GnuPG Key: D6180C26