Return-Path: X-Original-To: apmail-community-dev-archive@minotaur.apache.org Delivered-To: apmail-community-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D391910EDD for ; Mon, 10 Feb 2014 19:52:45 +0000 (UTC) Received: (qmail 60015 invoked by uid 500); 10 Feb 2014 19:52:42 -0000 Delivered-To: apmail-community-dev-archive@community.apache.org Received: (qmail 59733 invoked by uid 500); 10 Feb 2014 19:52:42 -0000 Mailing-List: contact dev-help@community.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@community.apache.org Delivered-To: mailing list dev@community.apache.org Received: (qmail 59723 invoked by uid 99); 10 Feb 2014 19:52:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Feb 2014 19:52:42 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of stephen.alan.connolly@gmail.com designates 209.85.160.48 as permitted sender) Received: from [209.85.160.48] (HELO mail-pb0-f48.google.com) (209.85.160.48) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Feb 2014 19:52:36 +0000 Received: by mail-pb0-f48.google.com with SMTP id rr13so6666499pbb.21 for ; Mon, 10 Feb 2014 11:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7DUmng99KA4uipeP8/xd8uTHJJZJx/bghJ7mASRfxWk=; b=HInHfhImWfHgjnpPbYyBFRs/Au07/45RQMFBxo4B4ABs4RZx4bv8V2J7/DMyiCEIVg +qoPmnaAXIfsELF+YGDJCt1lAi8ykDXDV6+e7iBskw1sTGRrdymQ2gLHmD5djDCzITOK U5LoK/vlF/cyI8l+N+x/PAxzJNzfyzffo2XIe+Nz+xZuvr1DkRcAJ/cE/f3+av+uR3P5 PSMvZYPSJKBfVwfPgsApEygv5FSDrK9wctKWxrv0rHM82dz7k+fnXLqLNP0l4OzyUvhX qvpElo15RRm4CMCAevrgGQGWQMDgfjsKSjk9loDR/U1riXU9FbkEDswYHmrtrDKHNgoV RhnA== MIME-Version: 1.0 X-Received: by 10.68.229.106 with SMTP id sp10mr39732624pbc.23.1392061934999; Mon, 10 Feb 2014 11:52:14 -0800 (PST) Received: by 10.68.147.102 with HTTP; Mon, 10 Feb 2014 11:52:14 -0800 (PST) In-Reply-To: <72416B14-E18A-4348-853A-16DE782397EC@jaguNET.com> References: <1392055524.8606.81644465.0F751D2A@webmail.messagingengine.com> <72416B14-E18A-4348-853A-16DE782397EC@jaguNET.com> Date: Mon, 10 Feb 2014 19:52:14 +0000 Message-ID: Subject: Re: How can we support a faster release cadence? From: Stephen Connolly To: "dev@community.apache.org" Content-Type: multipart/alternative; boundary=047d7b162c09241f5504f212ad35 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b162c09241f5504f212ad35 Content-Type: text/plain; charset=ISO-8859-1 On Monday, 10 February 2014, Jim Jagielski wrote: > > So, I could ask, what's special about 72 hours? > > It was to prevent things from sneaking out during a weekend So the release vote is scheduled for mid-week so that holiday weekends won't come into play... Ok you'll have St Patrick's day falling on the release day every 7 years or so... Same for the 4th of July and other national holidays but if that affects the vast bulk of the PMC then the PMC has a diversity problem ;-) > by a secret cabal when people are otherwise engaged... I also am assuming that the test suite for a release vote is either good or slow... If good it will catch problems... If slow then the RC will have been cut several hours before the vote is called... Further extending the time for people to register a "fall back to 72h" vote because you can see the "dodgy" commit of the cabal going in 6h before the release vote so that the test suite can start on the RC I don't think you can do fast cadence without tooling support or you will burn out the PMC and community... So to my mind tooling is a necessary requirement... These are not a set of isolated independent things... They are a combination of changes that conspire to find a second local minimum to the problem set, just a local min that has releases every week ;-) > Plus, > again, based on the old adage that people who are involved > are doing so *as volunteers*, and, as volunteers, there avail > cycles would ebb and flow, 72 hours was/is a nice compromise > to allow for semi-quick decisions but still enough time > so that people didn't consider all this effort as work, > instead of fun. > It can be fun getting your changes released every week and getting feedback from users... -- Sent from my phone --047d7b162c09241f5504f212ad35--