From: Markos Chandras <hwoarang@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
Date: Tue, 4 Dec 2012 09:23:05 +0000 [thread overview]
Message-ID: <CAG2jQ8ixNidz8jH4G3L-ZVQ+xXGvLCYDtuc98xf9yTJRUQ+Fyw@mail.gmail.com> (raw)
In-Reply-To: <50BDAFE2.6000702@gentoo.org>
On 4 December 2012 08:10, Rick "Zero_Chaos" Farina <zerochaos@gentoo.org> 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 : <maintainer><name>help welcome></name></maintainer>
> or a specific tag to put under our own maintainer section
> <maintainer><name>Rick Farina</name><demeanor>just fix it</demeanor></name>
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 <description> tag on metadata.xml you can use eg
<maintainer>
<email>foo@gentoo.org</email>
<name>Me</name>
<description>Primary maintainer but feel free to fix the bugs<description>
</maintainer>
--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
next prev parent reply other threads:[~2012-12-04 9:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-02 15:21 [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds hasufell
2012-12-02 15:38 ` Rich Freeman
2012-12-02 19:30 ` Markos Chandras
2012-12-04 1:18 ` Ben de Groot
2012-12-04 7:43 ` Ian Whyman
2012-12-04 9:19 ` Markos Chandras
2012-12-04 15:42 ` Alec Warner
2012-12-04 18:54 ` Markos Chandras
2012-12-06 10:53 ` Ben de Groot
2012-12-04 8:10 ` Rick "Zero_Chaos" Farina
2012-12-04 9:23 ` Markos Chandras [this message]
2012-12-04 16:01 ` Rick "Zero_Chaos" Farina
2012-12-04 17:06 ` Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds) Diego Elio Pettenò
2012-12-04 17:28 ` Rick "Zero_Chaos" Farina
2012-12-04 18:35 ` Sergey Popov
2012-12-04 18:48 ` Diego Elio Pettenò
2012-12-04 18:51 ` Markos Chandras
2012-12-06 11:02 ` Ben de Groot
2012-12-06 13:28 ` Markos Chandras
2012-12-06 15:27 ` Peter Stuge
2012-12-06 15:54 ` Ian Stakenvicius
2012-12-06 16:04 ` Peter Stuge
2012-12-06 19:07 ` Markos Chandras
2012-12-08 17:48 ` Jeroen Roovers
2012-12-04 17:01 ` [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds hasufell
2012-12-04 17:17 ` Rick "Zero_Chaos" Farina
2012-12-04 17:32 ` hasufell
2012-12-04 17:46 ` Rick "Zero_Chaos" Farina
2012-12-04 18:17 ` hasufell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAG2jQ8ixNidz8jH4G3L-ZVQ+xXGvLCYDtuc98xf9yTJRUQ+Fyw@mail.gmail.com \
--to=hwoarang@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox