Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 88556116FB for ; Thu, 3 Apr 2014 22:38:42 +0000 (UTC) Received: (qmail 79262 invoked by uid 500); 3 Apr 2014 22:38:41 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 79111 invoked by uid 500); 3 Apr 2014 22:38:39 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 78588 invoked by uid 99); 3 Apr 2014 22:38:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Apr 2014 22:38:37 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of busbey@cloudera.com designates 209.85.192.54 as permitted sender) Received: from [209.85.192.54] (HELO mail-qg0-f54.google.com) (209.85.192.54) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Apr 2014 22:38:32 +0000 Received: by mail-qg0-f54.google.com with SMTP id a108so2568176qge.13 for ; Thu, 03 Apr 2014 15:38:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=eSKHo6hp1yMLwVK3z64/a/jQ8y0XO2Ivt/4KPJ8rftA=; b=h4LxBpZvnO0qbzVnSQBDtAOZvaYbqiK+x1AQb9EHwCuQpelIoy0PjxNVhtlx+Z2Wr0 uUSW4GZHw1bWtFeaKCCBVdDggAxd5PigOYtERWGLK2zhNtToc3VWPLXPdz38/6RP843T g4h8Ak0QY4+NLxmuHtH3uDZknbMuM0KWrpE8vlXNYHvPE56YPAHw7uhbogv5xvCvgMZe aog9fNgP+k8VfxufzC0HesSdq1yvjYmt4MzX7WipqC28sxXIowi/eTtNVt+oWdetNAns 8bUOYzF6Vpuxix2Ct8N7KaQmN7lbQgoFg6vgt8vMi9QTnQ/pvY2QF1eZ9iQiWY39AgiX IpRA== X-Gm-Message-State: ALoCoQkDV1g/p5dUXMjm3HoA32XNhOQmgATCmipi2+1d2sfTZmCbpMphvAPtGDfOlqaVMZCp52oM X-Received: by 10.140.89.234 with SMTP id v97mr10069635qgd.20.1396564690448; Thu, 03 Apr 2014 15:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.232.65 with HTTP; Thu, 3 Apr 2014 15:37:49 -0700 (PDT) In-Reply-To: References: From: Sean Busbey Date: Thu, 3 Apr 2014 17:37:49 -0500 Message-ID: Subject: Re: [VOTE] Accumulo Bylaws, vote 2 To: "dev@accumulo apache. org" Content-Type: multipart/alternative; boundary=001a11c1161447c99504f62b0e33 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c1161447c99504f62b0e33 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi wrote: > On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki >wrote: > > > Going by the standards of a release vote, voting is actually the > appropriate time to discover fundamental issues. That's kind of the whole > point of voting -- getting people to agree that there are no fundamental > issues with what you're voting on. Finding valid, justifiable issues > should be welcome, as it results in a better product, whether the product > be a release or a community standard. > > > As an aside, this is not encouraged in our current release process. The test practices for a release take longer than the voting period for an RC. This directly implies that the fundamental issues must have been worked out prior to a call to vote. I've been fine with this interpretation, largely because it lines up with Apache guidelines around votes: do the consensus building work up front. If we're going to use a release vote as a time to do primary vetting, then we should probably change our RC vote window. --001a11c1161447c99504f62b0e33--