For reference, I've uploaded the branch to Apache ( https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=shortlog;h=refs/heads/ACCUMULO-3176) so you can see exactly what code changes we're talking about.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Nov 25, 2014 at 12:40 PM, Christopher <[email protected]> wrote: > As I see it, ACCUMULO-3089 is irrelevant to this vote. That issue may have > motivated the change, but the change is independent and can be considered > independently, but feel free to reference it as needed, since the > discussion did originate there. > > Also, I forgot to mention the timeline. The bylaws state a minimum 1 day > vote for code changes. So, this vote will expire at 1800 UTC, tomorrow, 26 > Nov 2014. (Although, we may continue resolving vetos to attempt to achieve > consensus after that, I imagine. Yes? This is kind of new territory...) > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > On Tue, Nov 25, 2014 at 12:28 PM, Mike Drob <[email protected]> wrote: > >> https://issues.apache.org/jira/browse/ACCUMULO-3089 for those of us who >> need it. >> >> On Tue, Nov 25, 2014 at 11:14 AM, Christopher <[email protected]> >> wrote: >> >> > Committers, this is a consensus vote on whether or not to include >> Jenna's >> > patch for ACCUMULO-3176 to the 1.7.0-SNAPSHOT (master) branch. >> > >> > This patch improves the table creation API with the introduction of a >> > NewTableConfiguration object (similar to the pattern for >> > BatchWriterConfig), which allows us to be flexible on improving table >> > creation options in the future without creating many overloaded methods >> (as >> > the table creation API has been plagued by in the past). The main goal >> of >> > the patch is to allow table properties to be set on a table at the time >> of >> > creation, before any tablets are assigned, but it also lays the >> foundation >> > for future table creation improvements. Creating initial table >> properties >> > was already present in the RPC calls, but not exposed in the API. This >> can >> > support a number of use cases. >> > >> > Since an objection was raised by Sean Busbey (and a veto expected), I've >> > initiated this vote in lieu of applying the patch under lazy consensus >> so >> > that any veto votes can be justified and addressed here. >> > >> > Note: there are a few bugs in the Mock implementation of this that I've >> > fixed, as well as some minor deprecation warnings and javadoc >> improvements >> > I'm adding, please apply your vote under the assumption that those will >> be >> > fixed before it will be applied. >> > >> > Please vote in accordance with the bylaws for consensus voting. >> > My vote is +1. >> > >> > Thanks. >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >
