Overall, in favor, but...
1. Confusing tag name
2. Alt. Option 1: just drop the active dev branch, no tag
3. Alt. Option 2: just closeout 1.4 with a quiet administrative 1.4.6
source release
4. Voting under "release" rules is invalid without signed release artifacts


Overall, I'm in favor of EOL'ing 1.4.x, but I'm not sure what an
"1.4.6-eol" tag in SCM would mean to users. The "-eol" suffix couldn't
really be documented anywhere for users to understand how that would
differ from an actual release/tagged version, for users browsing the
SCM tags. I understand a tag is not a release, but to a user, that may
not be clear. It's also very confusing, because it does look like an
updated release... it has a 1-up version number over the last release
(1.4.5), after all. That's very confusing.

To alleviate the confusion, it may be better to call it "1.4-eol" or
something else to indicate that it's not a newer release than 1.4.5
(it's not a release at all).

An alternative option to the 1.4.6-eol tag: just drop the
development/planning branch. (This is the option that was exercised
when this decision was made for 1.3.x). All the relevant code is
merged to newer branches anyway, and the outstanding work planned for
a future 1.4.6 which will never come to pass is not useful to tag
distinctly. Besides, the HEAD commit of 1.4.6-SNAPSHOT will be around
indefinitely, as it's merged to master, so we could achieve a similar
purpose by simply noting its current HEAD commit
[5bd4465c433860624091b0d97892e02f58154e7a] in a message to the mailing
lists, for archival purposes.

Another option: do an actual release vote on a signed 1.4.6 source
artifact. It wouldn't be hard to pass, since 1.4.5 passed, and the
current state of the branch isn't substantively different. We could
just call this an administrative release... no need for release
announcements and such, but it would clear up the name confusion.
1.4.6 would be an actual thing at that point, voted on and approved
for release.

Also, I'm concerned that this is being treated as though it were a
release vote. A release vote requires signed release artifacts:

You can't issue a vote under our rules for releasing without providing
release artifacts on which to vote. While it may still be valid to
have a similar voting mechanism for this kind of thing, what you're
proposing is certainly not a release vote. And given that I can see
arguments for treating it as a release plan cancellation[majority],
though... or code change[lazy consensus]... or even adoption of new
code base[consensus], I think the bylaws may need some clarification
on EOL procedures/voting.

Christopher L Tubbs II
On Sat, May 3, 2014 at 4:41 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB