Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60062 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54123 invoked from network); 17 Apr 2012 08:24:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Apr 2012 08:24:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=bas@tobin.nl; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bas@tobin.nl; sender-id=pass; domainkeys=good Received-SPF: pass (pb1.pair.com: domain tobin.nl designates 208.97.132.74 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: bas@tobin.nl X-Host-Fingerprint: 208.97.132.74 caiajhbdcahe.dreamhost.com Linux 2.6 Received: from [208.97.132.74] ([208.97.132.74:50740] helo=homiemail-a7.g.dreamhost.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 72/93-34429-CA82D8F4 for ; Tue, 17 Apr 2012 04:24:13 -0400 Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 6878325C064; Tue, 17 Apr 2012 01:24:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=tobin.nl; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=tobin.nl; b=Gtyr+aglsi7N7ee0 RjwaYQlq2ocQQ7domXfwf3qsXZ22CN6jgKTbkTB1Nwz6qoIBp9UR13Hh39Lbxlxl 8ecKHu50aVyFZtmAD5HpsUW5Fc9TVF9Wj+Gelugo99EvCvt7m8+6rhNV+a9zOBIB xyQrw2J84WWRvY4yuV4AsuMbX5Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tobin.nl; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=tobin.nl; bh=rDuWT/3C CCVTksawt0TjIokUByo=; b=Z3D/nKeHhZ3F9MMqd94pHNfYigPC4mnyP/J8nzbY Spu/3xAibOt2of2wnkQ8UP2dzuFDWCZxENr3ZmvTjfHH0ZFjH44s21aYlvtPbm1M QCmBQa4E8EcDXfjONVQx1OhrXwXWW3Px3+tQOATqxsIIFtyB3eCUsOvqvSQAj/wH oGk= Received: from [109.38.157.182] (unknown [109.38.157.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bas@tobin.nl) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 0BC7625C06A; Tue, 17 Apr 2012 01:24:07 -0700 (PDT) Message-ID: <4F8D28A1.6030903@tobin.nl> Date: Tue, 17 Apr 2012 10:24:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hannes Magnusson CC: Stas Malyshev , PHP Internals References: <4F82878A.6030609@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] release process with git From: bas@tobin.nl (Bas van Beek) Op 17-4-2012 9:47, Hannes Magnusson schreef: > On Mon, Apr 9, 2012 at 08:54, Stas Malyshev wrote: >> Hi! >> >> 5.4.1 will be the first release we're releasing using our new git setup. >> I would like to refine a process that we used to have for releases and >> make small tweaks hopefully to allow us more predictable release >> schedule and faster releases. >> What I am proposing is the following: >> 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is >> done on Monday/Tuesday (days can be tweaked back&forth a bit, but I >> assume we'll usually release on Thursday and count back from that). > (tiny hijacking). > > The whole point of releasing on Thursdays is so sysadmins have the > chance to update their servers in the event of known security problems > "before the weekend". > This point however becomes void when we release late Thursdays evening > American time, and we could just as well release on Saturday nights as > noone in Europe will be able to update their servers, and the > Americans will probably not be updating theirs either when they notice > the release Fridays after lunch. > > Even keeping in mind most sysadmins probably use distro packages, > these packages won't be built by their maintainers late Fridays and > therefore never rolled out to the public until after the weekend. > > If we however switch to Tuesdays we atleast give the sysadmins (and > package builders) a fighting chance of not needing to decide between > running possibly very unsecure environment over the weekend or risk > breaking the production environment due to unforeseen mishaps. > > Could we swap the release day to Tuesday? > Or atleast very very very very early morning Thursdays? > > -Hannes > Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. Bas