accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes
Date Mon, 12 May 2014 17:49:37 GMT
The goal here isn't just to insert a mechanical change to the SCM and
change the workflow. The goal is to try to orient ourselves to provide
faster bugfix deliveries on supported releases, while shifting the
focus of active development on major/minor releases.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, May 12, 2014 at 11:44 AM, John Vines <vines@apache.org> wrote:
> Why eliminate the 1.6.1-SNAPSHOT branch for 1.7.0-SNAPSHOT? Why not just
> branch the master and insert a 1.7.0-SNAPSHOT into our workflow after
> 1.6.1-SNAPSHOT and before master?
>
>
> On Mon, May 12, 2014 at 11:10 AM, Bill Havanki <bhavanki@clouderagovt.com>wrote:
>
>> I like this plan overall. I am definitely in favor of more frequent,
>> lighter-weight bugfix releases. We can start to move toward a regular
>> schedule of them, based on whether there is enough there to warrant one
>> each month / two months / whatever.
>>
>> We could start by branching off 1.6.0 now, and merging in whatever bug fix
>> commits make sense (pending a discussion as Christopher suggested). It can
>> be kept in a ready-to-release condition, for whenever it's "time" for
>> 1.6.1.
>>
>> What about 1.5.x? That will still receive feature changes as well as bug
>> fixes, I assume, until it goes EOL.
>>
>>
>> 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.
>> >
>>
>>
>>
>> --
>> // Bill Havanki
>> // Solutions Architect, Cloudera Govt Solutions
>> // 443.686.9283
>>

Mime
View raw message