From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C5DD5139694 for ; Fri, 21 Jul 2017 05:11:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F3D8EE0AF0; Fri, 21 Jul 2017 05:11:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BC423E0AF0 for ; Fri, 21 Jul 2017 05:11:18 +0000 (UTC) Received: from [10.61.74.72] (watch.civica.com.au [203.56.2.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: wraeth) by smtp.gentoo.org (Postfix) with ESMTPSA id 306AC341732 for ; Fri, 21 Jul 2017 05:11:15 +0000 (UTC) Subject: Re: [gentoo-proxy-maint] [RFC] New doc & policy To: gentoo-proxy-maint@lists.gentoo.org References: <1500537721.746.2.camel@gentoo.org> <9c69a6d7-2411-8f85-4638-6336a6d1202c@gentoo.org> <1500563738.746.8.camel@gentoo.org> From: "Sam Jorna (wraeth)" Message-ID: <9bf5f0e1-4db4-3ce9-b619-bc64b6beef22@gentoo.org> Date: Fri, 21 Jul 2017 15:11:03 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Proxy Maintainers X-BeenThere: gentoo-proxy-maint@gentoo.org X-BeenThere: gentoo-proxy-maint@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1500563738.746.8.camel@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Sr1FMCo8IuM4pc8xaa0aKKJpU8ak8bj0o" X-Archives-Salt: aa328387-94b9-4ebe-ae57-d02d208bbf89 X-Archives-Hash: 7a51ed75306b5573e33ec88e07aeb798 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Sr1FMCo8IuM4pc8xaa0aKKJpU8ak8bj0o Content-Type: multipart/mixed; boundary="EMdmmnrjtMbq24vApEqWsXnsVtusoQKNk"; protected-headers="v1" From: "Sam Jorna (wraeth)" To: gentoo-proxy-maint@lists.gentoo.org Message-ID: <9bf5f0e1-4db4-3ce9-b619-bc64b6beef22@gentoo.org> Subject: Re: [gentoo-proxy-maint] [RFC] New doc & policy References: <1500537721.746.2.camel@gentoo.org> <9c69a6d7-2411-8f85-4638-6336a6d1202c@gentoo.org> <1500563738.746.8.camel@gentoo.org> In-Reply-To: <1500563738.746.8.camel@gentoo.org> --EMdmmnrjtMbq24vApEqWsXnsVtusoQKNk Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: quoted-printable On 21/07/17 01:15, Micha=C5=82 G=C3=B3rny wrote: > On czw, 2017-07-20 at 19:36 +1000, Sam Jorna wrote: >> On 20/07/17 18:02, Micha=C5=82 G=C3=B3rny wrote: >>> * ability to request keywording on additional architectures (but note= >>> that most of arch teams are against proactive keywording) and to requ= est >>> stabilization; >> >> Stabilisation requests can also be filed by users per [1] without bein= g >> the maintainer. >=20 > 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 that you can already do anyway". >>> * ensure that the package follows the best practices (preferably of o= ur >>> own accord), >> >> I'm not sure what this wording is supposed to mean. >=20 > 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 t= he >>> top quality. Once the package is ready, we will merge it and close th= e >>> relevant bugs (if there are any). >> >> The bugs should probably be assigned to the maintainer for them to clo= se >> (if suitable) or otherwise deal with, as described below. >=20 > 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 foll= ow >>> the best git practices (atomic changes, proper commit messages). For >> >> A link to [2] or [3] may be useful here (or, at least, /somewhere/). >=20 > 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 repoman full -e y to verify the= >>> experimental profiles. >> >> What about developer profiles (`repoman full -d`) and checking metadat= a >> (`repoman full -x`)? >=20 > 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. >=20 > 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. >>> =3D=3D=3DKeywording & stabilization=3D=3D=3D >>> As a proxied maintainer, you can request [https://devmanual.gentoo.or= g/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. >=20 > 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. >=20 > 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. --=20 Sam Jorna (wraeth) GnuPG ID: D6180C26 --EMdmmnrjtMbq24vApEqWsXnsVtusoQKNk-- --Sr1FMCo8IuM4pc8xaa0aKKJpU8ak8bj0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJGBAEBCAAwFiEEkOOCivPPbnU/QAv/9azmicmnVzwFAllxjOwSHHdyYWV0aEBn ZW50b28ub3JnAAoJEPWs5onJp1c8jj4QAJHvYlJyKqc43cCRUFVkVvlsoQvcAOQS JnnNN28GroIcQF2OmrMG5GvXCIJBI2p3QMtq5BOD/oUGOfNR0pxkO0BFI3E2coRE 5YM8/nOPxuWGg+jDH6mI8Nh55WYMrIOpZY8SpKu/BkAbUxOTDILYgoLW02mtLWh4 2kAwBEln0q+ee3sF3sTlID2qkOQEZRkrMIQgOX8hDTcQo2y0kewBg6DaVp5yeRPp PCliQdGZei41yNQ8l4F+uhigP8Z6TKlfU2JCAYkEdynlRqLq9eU7AVWkQrnyVMT4 b/ALtki32Z0BsDqC5c2aqAXPvr4YyxKgZqLbvyaI3XP9yj7Z7UoX2AFxhUg3tNHS ek0N0kb9R1clWlJatg0p7Xk783r7qaXISoKzq+1ADWwZjt4alP/T+zWJicm2NJo7 p7GKO5JallEphs2QtPcgEwt5lqU11K7As6d808cOy84TcqV3K3fBRjScyodqo+vZ JEnjJhlDkXa4UCQ4Qgrs2OTzaiIOQiwZN3A9tnUxNui6odukpjj/RliG2nazV2v5 jU0nqEd0mrPO29RsnDxC8h4+REA+rF7YLiphZwwJxsFXmAFnM5IfxImWZ4ORd/LN j6oO9LzYFP8kEVfseNjzfEThSXFPpy9DB6jVn0p0E022SXpZpOVI5mms0GYWeW/2 b0TdgD+KpM2G =BVvL -----END PGP SIGNATURE----- --Sr1FMCo8IuM4pc8xaa0aKKJpU8ak8bj0o--