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 31ADE1731A for ; Tue, 7 Oct 2014 04:16:04 +0000 (UTC) Received: (qmail 29308 invoked by uid 500); 7 Oct 2014 04:16:04 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 29264 invoked by uid 500); 7 Oct 2014 04:16:04 -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 29251 invoked by uid 99); 7 Oct 2014 04:16:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Oct 2014 04:16:03 +0000 X-ASF-Spam-Status: No, hits=-0.4 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_RHS_DOB X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com designates 209.85.192.48 as permitted sender) Received: from [209.85.192.48] (HELO mail-qg0-f48.google.com) (209.85.192.48) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Oct 2014 04:15:59 +0000 Received: by mail-qg0-f48.google.com with SMTP id i50so4684113qgf.7 for ; Mon, 06 Oct 2014 21:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=i2rN39Hrpcs7gI3VpV/p4PBt6k3JZoXOufZycVlQ7m8=; b=tDsii0dL5PputEC86I073ClpxwCMjYFAolR68DaW1XxKtJBPCMFVsLFh6eqUKFEgQZ 8BpkjUCffDrAWN3sOjeoleiwjy+sD3ZfYQsfbzc7IN7FAxJlU/l95PUq8VmMsbnApEvl rEAxhNr1YvQriU6iVIVS4ncags2BxbC20Q5dxiQihjN7mW8G0v7UlATr7j0p4UbVkCMX Zf6Qw+MxDEfRGUATNhPhgbH8zVJhK1oIpfDKWV0RoH9HFoSlzw84/RJVZ7iKDqhmFKLI m7xYN6OzTFxB2o0s16BnGwcdCDehdTxD+R3rLSuAPsPqU5YPT20nAjXu1Iv81mLT7NEz A5nw== X-Received: by 10.224.60.193 with SMTP id q1mr1155373qah.12.1412655338062; Mon, 06 Oct 2014 21:15:38 -0700 (PDT) Received: from HW10447.local (pool-71-166-48-47.bltmmd.fios.verizon.net. [71.166.48.47]) by mx.google.com with ESMTPSA id w6sm14201910qas.26.2014.10.06.21.15.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 21:15:37 -0700 (PDT) Message-ID: <543368E6.7020902@gmail.com> Date: Tue, 07 Oct 2014 00:15:34 -0400 From: Josh Elser User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dev@accumulo.apache.org Subject: Re: 1.7 release timeline References: <5433360C.3020601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Oh, please, no worries. Part of figuring out the timeline for certain is to figure out what we plan to accomplish! Happy to see productive conversation on the subject. Christopher wrote: > Ah, I assumed it had instrumentation! Okay, cool. Thanks for the > clarification. So, I see that it definitely makes sense to work towards > merging htrace and cloudtrace/accumulo-trace, and fix the shortcomings as > it matures. (Now, back to the show/main thread. ;) ) > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > On Mon, Oct 6, 2014 at 9:36 PM, Billie Rinaldi > wrote: > >> Zipkin is a possible replacement for our trace collection system. It does >> not provide instrumentation like cloudtrace or htrace, so even if we make >> zipkin the default collection system we will still need instrumentation. >> Anyway, we can discuss the details and approach elsewhere. I'd certainly >> want the trace work to be in 2.0, but if we decide not to put it in 1.7 >> that would be okay. >> >> On Mon, Oct 6, 2014 at 5:59 PM, Christopher wrote: >> >>> Would replacing cloudtrace be part of 1.7? I'm not sure about that. I'd >>> like to see where that's headed before we decide on that. Personally, I'd >>> prefer Zipkin, since htrace is basically a copy of >>> cloudtrace/accumulo-trace, and it has some of the same issues (millis >> time, >>> for instance, instead of relative nanos, which is independent of the >> system >>> clock and actually intended for time spans). >>> >>> I think the upgrade guarantees are more a 2.0.0 thing, but I think we can >>> be a bit more conservative in 1.x to move towards that. I wouldn't mind >>> dropping Hadoop 1 support in 1.7.0. (I guess we should just vote on >> that). >>> I'd really like to include the VolumeChooser improvements (in particular >>> ACCUMULO-3177, which depends on ACCUMULO-3176). >>> >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> On Mon, Oct 6, 2014 at 8:38 PM, Josh Elser wrote: >>> >>>> Thanks, John. >>>> >>>> I was thinking about trying to gun for January time-frame for a >> release. >>>> I'd love to say before 2014 is over, but that probably just won't >> happen >>>> for a major release with the holidays. >>>> >>>> For 1.7 right now, I see the following "bigger" items (correct me where >>>> I'm wrong): >>>> >>>> * Replication (done) >>>> * Upgrade rules/guarantees (proposed) >>>> * Replace cloudtrace (in-progress) >>>> * Rewrite monitor, include REST service (in-progress) >>>> * Drop Hadoop 1 support (proposed) >>>> * Decouple MiniAccumulo from ITs (in-progress) >>>> * Other minicluster types: in-process, shim to real instance >>> (in-progress) >>>> * Support Hadoop metrics2 (proposed) >>>> * A few WAL/metadata related performance improvements (in-progress) >>>> >>>> Also, would be good to check the In-Progress state issues on JIRA. What >>> do >>>> people think? >>>> >>>> >>>> John Vines wrote: >>>> >>>>> Moving this to it's own thread... >>>>> >>>>> On Mon, Oct 6, 2014 at 5:54 PM, Mike Drob >> wrote: >>>>> Related: Do we have a release timeline for 1.7? >>>>>> >