accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Reduced testing burden for bug-fix releases
Date Mon, 23 Jun 2014 19:52:28 GMT
On 6/23/14, 3:31 PM, Sean Busbey wrote:
> I realize we're past window here, but a few things:

It's ok. I only remembered about this early today.

> 1) I'm concerned about changing our testing standards prior to getting some
> practice in on holding to tighter bounds on what can go into a particular
> kind of fix number. However, I generally like the idea of just relying on
> people voting -1 for insufficient testing.
> 2) We really could have used a [VOTE] on changing 1.x versions to use
> bugfix for the last number. It would be an opportunity to formally adopt
> our release governance docs into the PMC bylaws by reference.

I don't see this as a huge issue since everyone seemed to be in 
agreement on it. Writing it down for reference would be good for future 
discussions on the subject.

> 3) As a point of principle, David's veto was completely valid as it stood.
> While we are individuals it's perfectly reasonable for the PMC to set
> requirements on what goes into a release we sign off on, even if the PMC
> members may not always have ready access to the resources needed to meet
> that standard.
> There's no reason David should have to volunteer resources to back up his
> veto, especially when it was merely calling for a continuation of the
> standard we already had set.

That's why I said "Unless you are willing to supply the funds to pay to 
use some resources, I don't feel like this is a valid -1." If he, or 
anyone, is willing provide general resources for testing, that's a 
different story. Given his response, I assume that is not the case.

> 4) While I'm not in a position to obligate Cloudera, the team I'm on
> currently has been allocated sufficient resources to meet the current
> testing standards for a release and I have no reason to believe we won't
> have said resources when future release windows happen.

This would require time from you, Mike or Bill H, yes? While having some 
dedicated resources is nice, I'm worried about relying on other people 
(who have their own obligations) to fulfill the release manager's 

I think that gets into the details which the release manager can 
coordinate and other devs can express their concerns via the normal 
release voting process.

> -Sean
> On Thu, Jun 19, 2014 at 3:03 PM, David Medinets <>
> wrote:
>> +0 I'm changing my vote after some reconsideration. Having the ability
>> to vote -1 on a release as Keith mentioned is good enough for a
>> bug-fix release.
>> On Thu, Jun 19, 2014 at 3:20 PM, David Medinets
>> <> wrote:
>>> -1 I hesitate to step into this discussion because I can't also step
>>> up and do the long-term testing even as I recommend that it must be
>>> done. There are at least four companies supporting Accumulo and
>>> contributing back to the project. Surely one of those companies can
>>> supply the resources to continue the existing test regimen? Is there
>>> some concern that those resources won't be available for the next
>>> release cycle?
>>> On Thu, Jun 19, 2014 at 3:13 PM, Josh Elser <>
>> wrote:
>>>> As we're starting to consider 1.5.2 and 1.6.1 coming out in the near
>> future,
>>>> I want to revisit a discussion[1] I started at the end of April
>> regarding
>>>> the "testing burden" that is currently set forth in our release
>> document[2].
>>>> What I'm proposing is to modify the language of the release document to
>> be
>>>> explicit about the amount of testing needed. For bug-fix, "minor"
>> releases
>>>> (e.g. 1.5.2 and 1.6.1), the 7 days of testing using continuous ingest
>> and
>>>> randomwalk (with and without agitation) will be clearly defined as "may"
>>>> instead of "should" or "must" language. If the resources are available,
>> it
>>>> is recommended that some longer, multi-process/node test is run against
>> the
>>>> release candidate; however, it is not required and should not prevent us
>>>> from making the minor release.
>>>> I will also include language that strongly recommends that the changes
>>>> included in the "minor" release be vetted/reviewed as a way to mitigate
>> the
>>>> risk of shipping new regressions.
>>>> I am not recommending that the language be changed for "major" releases
>>>> (e.g. 1.7.0 and 2.0.0) as these releases still imply significant new
>>>> features or internal changes.
>>>> Unless someone informs me otherwise, I will treat this as a normal
>>>> lazy-consensus approval. Assuming we move closer to "proper" semantic
>>>> versioning for 2.0.0, I believe these updated guidelines will change
>> again.
>>>> I do however think there is merit in making this change now so that we
>> can
>>>> get the good bugs that we've fixed out to our users.
>>>> Let me know what you think. I will wait, at least, the prescribed three
>> days
>>>> before changing any thing.
>>>> - Josh
>>>> [1]
>>>> [2]

View raw message