Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGHyZ6+bs6T-iQc7XBhz3hwD8FMGC70KJJApsim=NkgRsNNCDg@mail.gmail.com>
References: 
 <CAL5zq9Yycv7Rt++uBHKJR44qkhouOnfz0dQMdQiSp7tSBJNBug@mail.gmail.com>
	<CAGHyZ6+vmep3UcgS0Q83zTZpcZ_UuNKK8yHjuHT7yMM5UR1eLw@mail.gmail.com>
	<CAGHyZ6+bs6T-iQc7XBhz3hwD8FMGC70KJJApsim=NkgRsNNCDg@mail.gmail.com>
Date: Tue, 12 May 2015 15:42:45 -0400
Message-ID: 
 <CAL5zq9Yp7bHzXiPjMD3BoeBgnQ=XbO+94T5Qd-uv_x0ynYW2xw@mail.gmail.com>
Subject: Re: [DISCUSS] EOL 1.5
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: text/plain; charset=UTF-8

Feel free to include user@ sooner, if you wish. The reason I hadn't
already was because my suggested route would only be a shift in
development procedures, and wouldn't really change things from a user
perspective. Alternatives to what I suggest may affect them more
strongly. We definitely should CC them when we have a decision,
though.

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


On Tue, May 12, 2015 at 2:55 PM, Sean Busbey <busbey@cloudera.com> wrote:
> 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