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

[Sam Jorna (wraeth)]

On 21/07/17 01:15, Michał Górny wrote:
> 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.

Fair enough, just was worried it was a "you get <this thing> that you
can already do anyway".

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

I think how you have it now (v2) is good.

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

Right, I was thinking maintainer-needed.

>>> 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 links that are there at present, plus your suggestion about a
reference list on the main page below, should be enough I think.

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

I remember reading somewhere that repoman didn't check metadata.xml by
default, though I can't find that reference any more. It could be
out-of-date information, or I may have mis-remembered.

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

A previous incarnation of the stablereq policy had users CC'ing relevant
teams after a timeout. How that works with the bot now I'm not sure.
Either way, I'm happy with how this is now.

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

No, it came across as that your Bugzilla address and maintainer address
per metadata.xml did not have to be the same, so long as you added a
comment to the bug noting your maintainer address. I think this is
adequately covered now.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26