+1 Seems like no one is pushing for a longer lifetime for 1.5. 1.5.3
makes sense.
Eric Newton wrote:
+1 for EOL for 1.5.
Making fixes in 1.5 and then merging it to 1.6, 1.7, and then master is
tedious work. 1.5 makes the task more challenging because the layout of the
packages changed so much in 1.6.
-Eric
On Thu, May 21, 2015 at 1:18 PM, Christopher<ctubb...@apache.org> wrote:
So, at this point, I'm willing to do a 1.5.3 release and can start
that today. It seems we're in agreement we should at least do that.
Beyond that, I'm not really sure what the consensus is.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, May 12, 2015 at 10:35 PM, Josh Elser<josh.el...@gmail.com> wrote:
1.5 has already started to suffer in terms of landing every bug-fix
there. I
don't think it's intentional (I know I have done it though), but it's
kind
of a sign that the devs have already mentally move beyond 1.5.
I think JIRA is a clear sign that users aren't heavily using 1.5 (I can't
think of more than a couple tickets marked as affects 1.5.x), but it
would
be nice to explicitly ask user@.
A 1.5.3 to close things out would be nice -- can always be re-opened if
someone wants to scratch that itch.
Sean Busbey 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<ctubb...@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<bus...@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<bus...@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<ctubb...@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
