accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [DISCUSS] EOL 1.5
Date Tue, 12 May 2015 18:55:06 GMT
oh! almost forgot. We should get user@accumulo into this conversation
sooner rather than later. I'm not sure if it's  better ot just copy them in
to this thread or do it as a follow up once we have more of an idea of what
"EOL" means for them.

On Tue, May 12, 2015 at 1:53 PM, Sean Busbey <busbey@cloudera.com> wrote:

> +1 to making sure we have a 1.5.3 before stop dev
>
> I'd like to make sure we get through some testing of 1.5 -> 1.7 upgrade
> testing before declaring dev over, just to give people more assurance that
> they can upgrade off of the version.
>
> On Tue, May 12, 2015 at 1:18 PM, Christopher <ctubbsii@apache.org> wrote:
>
>> How do we want to EOL 1.5?
>>
>> Personally, I was thinking (soon after 1.7.0 is released):
>> * Release and tag 1.5.3
>> * Remove 1.5 branch to focus active development on newer versions
>> * Be willing to branch from the 1.5.3 tag to rapidly release a 1.5.4
>> in response to critical bugs
>>
>> My biggest concerns are:
>> 1) We turn exhausted people off by doing burdensome release testing,
>> which delays bugfixes in 1.5, and
>> 2) We get into a situation where 1.5.3 has some bugs that we never
>> fix, which sends a confusing message to stick with 1.5.2.
>>
>> There's also the concern that there's a fair amount of work that was
>> put into 1.5.3, and I'd hate to have those contributions not be
>> available to users of 1.5.
>>
>> I figure that so long as we're willing to fix critical bugs, we can
>> formally cease active development (EOL), without going so far as to
>> say that 1.5 users are completely screwed if a critical bug is
>> identified.
>>
>> What I'm describing isn't really an EOL date, so much as an EOL period
>> which begins when we cease active development on 1.5, and ends
>> organically at some arbitrary point in the future when people stop
>> reporting critical bugs (or we reach a point where maintaining it is
>> too costly... a sort of "EOL-2").
>>
>> Another way to look at what I'm suggesting is switch from a "sustained
>> development" model to a "branch to fix and release" model, where
>> patch/bugfix releases are more narrowly scoped and can occur more
>> rapidly, on demand.
>>
>> Thoughts? Alternatives? Variations? Objections?
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>
>
>
> --
> Sean
>



-- 
Sean

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