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

[Michał Górny]

On czw, 2017-07-20 at 19:36 +1000, Sam Jorna wrote:
> 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.

This is not the point. The point is, you can't file
a keywordreq/stablereq against a package that's not in ::gentoo. So
being a proxied maintainer means you can submit a package that will go
stable.

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

Good catch.

>
> > * ensure that the package follows the best practices (preferably of our
> > own accord),
>
> I'm not sure what this wording is supposed to mean.

That was supposed to be 'your own accord'. The generic idea is that we
want proxied maintainers to use newest EAPI, follow current policies
and so on. Should I give those examples in the doc?

> > ==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.

I'll think how to reword that.

>
> > 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.

It's about maintainer-wanted bugs. I don't really see a reason to
reassign this kind of bug and tell maintainer to close it afterwards.

> > * 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.

This is documentation of proxy-maint project, so working outside proxy-
maint is really irrelevant here.

> > ===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.

I can make it 'most efficient' if that makes you sleep better. Fact is,
pull request can get reviewed and merged within a few days. Bugs rot.

> > 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/).

Yeah, I'm still thinking of how to solve this best. Maybe a separate
section on git with links would be helpful, since right now things seem
to be a little split between the three methods.

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

Done.

>
> > 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`)?

Out of scope. I wanted only to give the generic note that things won't
work out of the box for the common case of ~arm64.

It's first time I hear that I need '-x' for anything. Why is that?

> > ===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 point is that you need approval from proxy-maint. Compare with
today's bug when an user CC-ed arches on a bug that hasn't even been
assigned.

> > ===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.

Are you suggesting that I make it 'submit an update ... first'?

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

Yeah, extraneous '['. Fixed now.

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

I was thinking about it but I think they'd be better on top-level proxy-
maint project page.

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

-- 
Best regards,
Michał Górny