accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] EOL 1.5
Date Tue, 12 May 2015 22:08:53 GMT
That should read "that could be a good thing" (rather than "that's a
good thing"... I don't know which procedure is better).

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


On Tue, May 12, 2015 at 6:05 PM, Christopher <ctubbsii@apache.org> wrote:
> The rate is already slow, but I understand your point.
>
> And, yes, you are correct, it would likely affect how far back
> developers finding bugs in newer versions look to determine the oldest
> affected version. In my view, that's a good thing, because it means
> less wasted effort if nobody is using those older versions. It puts a
> little more onus on users to report bugs against older versions when
> they encounter them, rather than developers to assume it's worth going
> back that far.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, May 12, 2015 at 4:22 PM, Sean Busbey <busbey@cloudera.com> wrote:
>> that change to development procedure will definitely impact them. it'll
>> mean folks no longer look for their bugs to impact the 1.5 branch to start
>> (unless things are critical). that basically guarantees that the rate of
>> 1.5 releases will slow, which impacts ops planning for those on the 1.5
>> line.
>>
>> On Tue, May 12, 2015 at 2:42 PM, Christopher <ctubbsii@apache.org> wrote:
>>
>>> 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
>>>
>>
>>
>>
>> --
>> Sean

Mime
View raw message