accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] ACCUMULO-3176
Date Wed, 03 Dec 2014 14:35:08 GMT
On Dec 3, 2014 9:32 AM, "Sean Busbey" <busbey@cloudera.com> wrote:
>
> On Tue, Dec 2, 2014 at 1:34 PM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > Let's please try to not get snarky here, Dave. We're all trying to have
a
> > reasonable discussion, get to the real issues, and figure out how we can
> > work through them without stomping on anyone. As always, you are
welcome to
> > fork for you personal reasons -- I don't want to force you down that
path,
> > but this is going to take some more time to resolve.
> >
> > Obligatory thank you to Sean for writing up his opinions: it helps us
all
> > understand what would be acceptable presently for him to retract his
veto
> > in addition to what he sees as the current issues.
> >
> > What I took away from his response: we need to (re)visit what 1.7.0 is
> > really going to be. Rightfully so, we left 1.7 as a intermediate
release to
> > let us continue to develop, with the intent to do 2.0.0 as the next
fancy
> > thing. Assuming that is still the plan (which has not been otherwise
> > changed), Sean's objection is reasonable. API changes definitely doesn't
> > seem to be in scope for something that was to be a very minor "major"
> > release.
> >
> > That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
> > started considering 1.7.0 to be another "normal" major release, rather
than
> > a "minor" one. If we're all in agreement here, I think it would make
sense
> > to apply our normal API rules to 1.7.0 and then make sure we minimize
churn
> > between 1.7.0 and 2.0.0 for any additions.
> >
> > Sean, is that an acceptable avenue to redirect this discussion? Have I
> > missed any other sticking points? That the above wouldn't address?
> >
> >
>
> Yes, that's reasonable.

Great. Thanks.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message