Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63032 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96052 invoked from network); 17 Sep 2012 14:44:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Sep 2012 14:44:38 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 config.schlueters.de Received: from [217.114.211.66] ([217.114.211.66:49178] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 12/03-07072-55737505 for ; Mon, 17 Sep 2012 10:44:38 -0400 Received: from [192.168.2.230] (ppp-88-217-69-121.dynamic.mnet-online.de [88.217.69.121]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id D2712632EC; Mon, 17 Sep 2012 16:44:33 +0200 (CEST) To: David Soria Parra Cc: internals@lists.php.net In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Sep 2012 16:44:33 +0200 Message-ID: <1347893073.5709.2986.camel@guyrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Moving forward: PHP 5.5 From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) Hi, On Sat, 2012-09-08 at 07:49 -0400, David Soria Parra wrote: > Let's keep things simple here, stay on topic and debate if we want to > start with 5.5 and who can RM it. I wonder if we really need two RMs. This two-RM-thing was introduced back when I was busy with different things at work, university, live, ... when Lukas stepped in to do some of the administrative tasks. Nowadays those administrative tasks are ruled way more in RFCs and the role of the RM, in my opinion, is more a task overseeing things (reviewing changes, reminding people about their "promises") etc. in the end those are all things *everybody* should be doing. For the remaining coordination though there should be a single person, who can judge on implications, when there is doubt. I'd therefore suggest that we go back to a single RM. This gives one person to talk to, which eases communication a lot (even if the single RM just delegates the issue back to some domain expert). A single RM, of course, has the risk to "disappear" due to changes in life or whatever but I don't think that's a major risk as the role might transition. Such a transition might also be good when selecting a successor - throw a successor on the prepared path after the .0 is done instead of throwing them directly in the center of the field a short time before a release where everybody tries to get his things in. David, I think you're experienced enough to fill this role alone. Thanks, johannes