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: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes
Date Mon, 12 May 2014 22:22:54 GMT
On 5/12/14, 11:00 AM, Keith Turner wrote:
> On Mon, May 12, 2014 at 10:44 AM, Josh Elser <josh.elser@gmail.com> wrote:
>
>> On 5/12/14, 10:41 AM, Keith Turner wrote:
>>
>>> On Sun, May 11, 2014 at 6:54 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>>>
>>>   >SGTM. Looks like there aren't currently any fixes of much substance for
>>>>> 1.6.1 presently, but there are a few that would make for a very-low
>>>> impact
>>>>> 1.6.1, and a good 1.5.2 which also includes the fallout tickets shortly
>>>>> after 1.5.1. Timeframe looks good to me too.
>>>>>
>>>>> If we can get that reduced test burden for "real" bug-fix releases
>>>>> hammered out, a month sounds good to me.
>>>>
>>>
>>> Rather than reduce the test burden, it would be nice to make the cluster
>>> testing more automated like you and other have discussed.
>>>
>>
>> I think that would be a good parallel goal, but I would still think that 7
>> days of testing for a bug-fix release is excessive. Most times for me the
>> pain is getting resources to test for such a long period, not necessarily
>> setting up the test.
>>
>
>
> I see.  Wether or not the testing is excessive depends on the bug fixes.
> We could relax the goal and let decisions be made per release.  A possible
> way to do this would be to not require anything beyond mvn verify AND
> people can -1 a release if they do not think sufficient testing was done.
> This makes it easy to make the testing decisions per release using the
> existing release voting mechanism.

Absolutely, I wouldn't want to say that every bug-fix release need not 
be tested extensively for that exact reason. I like the idea you propose 
-- it would make us think more about what goes *into the release* as 
opposed to blindly assuming that the tests run actually exercise the 
code in the appropriate ways.

We could focus more assuring that we have proper coverage for the issues 
that caused us to make this release in the first place.

Granted, perhaps this is a bit tangential at this point... :)

Mime
View raw message