Gentoo Archives: gentoo-proxy-maint

From: "Sam Jorna (wraeth)" <wraeth@g.o>
To: gentoo-proxy-maint@l.g.o
Subject: Re: [gentoo-proxy-maint] [RFC] New doc & policy
Date: Fri, 21 Jul 2017 05:11:19
Message-Id: 9bf5f0e1-4db4-3ce9-b619-bc64b6beef22@gentoo.org
In Reply to: Re: [gentoo-proxy-maint] [RFC] New doc & policy by "Michał Górny"
1 On 21/07/17 01:15, Michał Górny wrote:
2 > On czw, 2017-07-20 at 19:36 +1000, Sam Jorna wrote:
3 >> On 20/07/17 18:02, Michał Górny wrote:
4 >>> * ability to request keywording on additional architectures (but note
5 >>> that most of arch teams are against proactive keywording) and to request
6 >>> stabilization;
7 >>
8 >> Stabilisation requests can also be filed by users per [1] without being
9 >> the maintainer.
10 >
11 > This is not the point. The point is, you can't file
12 > a keywordreq/stablereq against a package that's not in ::gentoo. So
13 > being a proxied maintainer means you can submit a package that will go
14 > stable.
15
16 Fair enough, just was worried it was a "you get <this thing> that you
17 can already do anyway".
18
19 >>> * ensure that the package follows the best practices (preferably of our
20 >>> own accord),
21 >>
22 >> I'm not sure what this wording is supposed to mean.
23 >
24 > That was supposed to be 'your own accord'. The generic idea is that we
25 > want proxied maintainers to use newest EAPI, follow current policies
26 > and so on. Should I give those examples in the doc?
27
28 I think how you have it now (v2) is good.
29
30 >>> Our team will review the submitted files and help you bring them to the
31 >>> top quality. Once the package is ready, we will merge it and close the
32 >>> relevant bugs (if there are any).
33 >>
34 >> The bugs should probably be assigned to the maintainer for them to close
35 >> (if suitable) or otherwise deal with, as described below.
36 >
37 > It's about maintainer-wanted bugs. I don't really see a reason to
38 > reassign this kind of bug and tell maintainer to close it afterwards.
39
40 Right, I was thinking maintainer-needed.
41
42 >>> It is recommended that you try to keep the same commit structure as
43 >>> you'd use when committing straight to Gentoo as a developer, and follow
44 >>> the best git practices (atomic changes, proper commit messages). For
45 >>
46 >> A link to [2] or [3] may be useful here (or, at least, /somewhere/).
47 >
48 > Yeah, I'm still thinking of how to solve this best. Maybe a separate
49 > section on git with links would be helpful, since right now things seem
50 > to be a little split between the three methods.
51
52 The links that are there at present, plus your suggestion about a
53 reference list on the main page below, should be enough I think.
54
55 >>> You need to explicitly use <kbd>repoman full -e y</kbd> to verify the
56 >>> experimental profiles.
57 >>
58 >> What about developer profiles (`repoman full -d`) and checking metadata
59 >> (`repoman full -x`)?
60 >
61 > Out of scope. I wanted only to give the generic note that things won't
62 > work out of the box for the common case of ~arm64.
63 >
64 > It's first time I hear that I need '-x' for anything. Why is that?
65
66 I remember reading somewhere that repoman didn't check metadata.xml by
67 default, though I can't find that reference any more. It could be
68 out-of-date information, or I may have mis-remembered.
69
70 >>> ===Keywording & stabilization===
71 >>> As a proxied maintainer, you can request [https://devmanual.gentoo.org/k
72 >>> eywording/index.html keywording and stabilization] of your packages.
73 >>> However, all those requests need to be approved by proxy-maint team
74 >>> member (or a regular developer co-maintainer) first.
75 >>
76 >> As mentioned previously, others can request stabilisation as well.
77 >
78 > The point is that you need approval from proxy-maint. Compare with
79 > today's bug when an user CC-ed arches on a bug that hasn't even been
80 > assigned.
81
82 A previous incarnation of the stablereq policy had users CC'ing relevant
83 teams after a timeout. How that works with the bot now I'm not sure.
84 Either way, I'm happy with how this is now.
85
86 >>> If you ever change your Bugzilla e-mail address, please remember to
87 >>> submit an update to your package {{Path|metadata.xml}} files. We will
88 >>> also note the new e-mail address on the maintainer bug.
89 >>
90 >> This implies maintainer address and bugzilla address may be different,
91 >> which will annoy bug wranglers to no end.
92 >
93 > Are you suggesting that I make it 'submit an update ... first'?
94
95 No, it came across as that your Bugzilla address and maintainer address
96 per metadata.xml did not have to be the same, so long as you added a
97 comment to the bug noting your maintainer address. I think this is
98 adequately covered now.
99
100 --
101 Sam Jorna (wraeth)
102 GnuPG ID: D6180C26

Attachments

File name MIME type
signature.asc application/pgp-signature