From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 12C161381F3 for ; Tue, 4 Dec 2012 16:00:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 26EC521C008; Tue, 4 Dec 2012 16:00:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7DB25E0587 for ; Tue, 4 Dec 2012 15:59:58 +0000 (UTC) Received: from [192.168.1.5] (pool-71-245-176-92.pitbpa.fios.verizon.net [71.245.176.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id 85B4D33D80D for ; Tue, 4 Dec 2012 15:59:52 +0000 (UTC) Message-ID: <50BE1E3E.9070406@gentoo.org> Date: Tue, 04 Dec 2012 11:01:02 -0500 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds References: <50BB71DD.4080308@gentoo.org> <50BDAFE2.6000702@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.4.6 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 2be507c9-6b61-4f5a-826d-12b81db0d2be X-Archives-Hash: 96c5e5aa0ab029d8973a618e7dafc8b4 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/2012 04:23 AM, Markos Chandras wrote: > On 4 December 2012 08:10, Rick "Zero_Chaos" Farina wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 12/02/2012 10:21 AM, hasufell wrote: >>> As I was told in my recruiting process we usually don't just fix up >>> ebuilds of other devs unless it's trivial, very severe or something. >>> >>> The usual process is nothing new: try to contact the maintainer, open a >>> bug, set a deadline when you will go and fix yourself. >>> >>> Only question is now what is a sane soft limit, before you go on and fix >>> stuff. >>> >From a discussion in #gentoo-dev we thought 2-4 weeks depending on the >>> severity of the bug is fine. Ofc this should exclude major changes or >>> delicate packages from base-system/core/toolchain. >>> >>> I tried to document that a bit: >>> https://bugs.gentoo.org/show_bug.cgi?id=445402 >>> >>> any objections? This is nothing new, just a clarification of already >>> existing policy and a reminder. >>> >>> >> If we are going to document this policy and make it official (which >> since it's not documented it's not official) then it only makes sense to >> have an opt-out option. I personally don't wish to see my users suffer >> for 2-4 weeks because I'm busy and people are pretending to be polite. >> >> I have no issue with this policy, but to do it without an explicit >> option to opt-out is not acceptable to me. I would suggest something in >> the metadata.xml under the maintainer section. We could have a specific >> maintainer section : help welcome> >> or a specific tag to put under our own maintainer section >> Rick Farinajust fix it > > Nobody said the opposite. The devaway message should always be checked > for people who appear to be inactive and if they > say "Do not touch my packages" then you shouldn't touch them even if > he doesn't even touch them himself. Let the retirement team > kick him out. > > There is always the tag on metadata.xml you can use eg > > > foo@gentoo.org > Me > Primary maintainer but feel free to fix the bugs > > foo@gentoo.org Me Proxy maintainer, assign bugs to proxied maintainer, cc on bugs, but feel free to just fix the bugs I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. - -Zero -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQvh4+AAoJEKXdFCfdEflKbp8P/2x+DGuDTlLv1ZKJjTQn1zpy nf6izcfmYcoqaGTIgL5ynFaGmv/H3U6LX42G/kL041bqUn9SjozM+liU+k0RzrQ1 SQcJUPs1tc4qzp+loWnXZnPDWmUJLkRI7n1B/O9SnvEl1g1LxXKmc2j9w51kYWmz 9Lowv3/CKGhWjow5A05DEzNya7bShjm/9tJulXltIL7H0IeC0cZGJeB5/cD7+Qfz TwugXiGNIWp0gErBUDa9wYdgzI2Z8LEc8IrQhUQS+56IF/ZNcwYP0zJi1S7YEYAs YVtCMPrUt/JmMKDluDlxQ9JXJ3YZkbz7Eb/iwAXFHlJYNWkf9hjWtQfDmzETx7xu wqNKF9m1IpoQANgsZRgsKdyAG56ELUW7QtfFNbVTYy0LGu36yZ2Hc3zbZNMvjZhP T8GYIF/5My89gNdBonHuZ7ub0zP1NpTFWI3qrNdzgI5Ko+aaH75y1Hz+puCwlHOG Ht0HbhpqRYidos2NSppecGhl9p5oZ8xZI/rVh/BgjtonJrXlIEfYzhUQHU4SzIxt v0hVJTIXq1RwE7gF4OGLEbpGTM5V0BcdT+FzSRuq5bJiAEvDLXIixdMh5kga6t7F e9H0iM5aRl9pxO1Rs0bOJmZhoZ+vwyOs/aPLYDNmNx8aNLicIWqfs2aGgjK7G8Y+ QYrB3h0du6gZymOZ+oys =IpQP -----END PGP SIGNATURE-----