accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [VOTE] Accumulo 1.5.4-rc1
Date Thu, 10 Sep 2015 21:23:48 GMT
We can't tie the ability to vote -1 on a release to volunteering to fix the
issue that causes a -1. Presuming a release is valued by the community, the
work will get done.

At the same time, it is crappy for Josh to be expected to fix everything,
especially if he doesn't want to fill the role of janitor. We all have
plenty of other things to do, but so does he.

So let's deal with the matter of the vote at hand first. After that we can
deal with fixing things, hopefully with Josh abstaining. (Josh I'd
recommend un-assigning yourself from the issue if you'd prefer someone else
take it up.)

-- 
Sean
On Sep 10, 2015 3:19 PM, "Josh Elser" <elserj@apache.org> wrote:

> Christopher wrote:
>
>> The larger concern I have is that expecting it to be fixed prior to 1.5.4
>> might mean loss of willingness to create an RC2 for 1.5.4 and release it
>> at
>> all. Recall, the 1.5 branch was only revived at all to fix some critical
>> issues and move on. It's still a viable alternative to abandon 1.5.x and
>> focus on fixing these issues in 1.6, and later, where we've made dramatic
>> improvements to the build. Fixing these newly identified issues is going
>> to
>> take some time and effort. It's not that it can't be done for 1.5.4... but
>> the question is... who is going to do it? Is anybody who issued a "-1"
>> willing to step up and resolve these issues? Or will it rely on Josh? I'm
>> currently looking at some of the issues to try to help out if I can, but I
>> also have other obligations.
>>
>>
> Thanks for consideration, Christopher.
>
> While people sharing their opinion is appreciated, a repeated reaction
> without offered effort put behind it can come across in bad taste. Not
> trying to do discourage the conversation I asked for, I just would love to
> come back and see a patch to _fix_ one of the many nits outlined instead of
> another "me too".
>

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