Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59572 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19355 invoked from network); 9 Apr 2012 22:21:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 22:21:18 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:60782] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1E/92-34074-DD0638F4 for ; Mon, 09 Apr 2012 18:21:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id C5BCC3003FE; Mon, 9 Apr 2012 18:21:14 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 878B830044E; Mon, 9 Apr 2012 18:21:14 -0400 (EDT) Message-ID: <4F8360DA.5060604@sugarcrm.com> Date: Mon, 09 Apr 2012 15:21:14 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Jones CC: PHP Internals References: <4F82878A.6030609@sugarcrm.com> <4F8356BA.1070904@oracle.com> In-Reply-To: <4F8356BA.1070904@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] release process with git From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I would like to see clarity on when fixes have been merged to the RC > branch (git emails are still a bit hard to grok). It would help to > have early communication about fixes you have decided against so we > can argue their merits and so we don't assume you are planning to pick > them up. So this is the main point I want to change. There will be no fixes "decided for" and "decided against". Once RC1 is out, this is by default the release, and all the fixes since this point go into version X+1. The only exception - and I can't emphasize enough that I want it to be exception, not a usual occurrence - if we have a critical issue in RC1. So by default no fixes are rejected and no fixes are merged - once RC1 is out, fixes are presumed to be in X+1 version. Unless you know this is a critical bug (meaning, there's absolutely no point releasing PHP with it as either one could not use it - e.g. it does not compile - or nobody in his sane mind would use it - e.g. remote security hole) there would be no point deciding or arguing about it. Again, this is a change from what we did before, not a big one, but as you can see it requires some mindset shift. I think it will improve our release process and will make us able to release quick and quality versions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227