On Tue, Aug 8, 2017 at 12:01 PM, Yu Li wrote:
...
> Maybe we could open several umbrellas in JIRA to follow up the
> implement-able topics and do some prioritizing? Thanks.
>
Agree.
Let me start up the DISCUSS suggested by Ashish; it just came up again on
the tail of an issue
St.Ack
>
(This came up during dev meeting in Shenzhen) We are running too many
branches and/or when applying patches, we do not do a good job backporting
to all active branches, especially fixes.
We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2, and
branch-1.1 active currently. If a d
We can change the AtomicLong to be AtomicReference which is
updated atomically.MemStoreSize can be changed to hold on-heap memory, off-heap
memory and data size, or just on-heap memory and off-heap memory if data size
is not required anymore.
On Monday, August 7, 2017, 10:23:12 AM GMT+3, Anoo
I totally agree we have too many branches to maintain.
I think we should EOL 1.1. 1.2 has been out and stable for a long time,
doesn't have any outstanding major problems preventing upgrade that I'm
aware of, though obviously Sean would know better.
Speaking of 1.3, there's one issue that I feel
Tamas Penzes created HBASE-18538:
Summary: deduplicate copies of jquery files
Key: HBASE-18538
URL: https://issues.apache.org/jira/browse/HBASE-18538
Project: HBase
Issue Type: Improvement
I'd love to see us more aggressively updating the stable pointer.
I spent a but of time at the last hbasecon west socializing more EOL, but
as Mikhail mentions we can't make 1.3 the stable line while we know it's
broken. AFAIK, that same problem is in brach-1.4.
We could immediately EOL 1.3 and t
Are we approaching this problem wrong though?
Most of the cherry picks I have to do to the maintenance release lines are
clean.
What if we get more tooling to help with the everything-goes-right case?
My last read of asf policy and infra folks (from back in the website
automation) is they won't
Build status: Still Failing
The HBase website has not been updated to incorporate HBase commit
${HBASE_GIT_SHA}.
See https://builds.apache.org/job/hbase_generate_website/1074/console
I think in the dev community interest and ultimately in interest of our
users to have a fewer maintained branches.
For a variety of reasons.
Efforts put in the maintenance of old release lines is the effort not put
into releasing new ones, since community resources are
finite. Active backporting
I can also start separate discussion thread on what prevents 1.3 (and 1.4
subsequently, though Andrew would be the right person here) from being
marked stable in our books, so this issue gets more focused attention.
-Mikhail
On Tue, Aug 8, 2017 at 8:10 AM, Mikhail Antonov
wrote:
> I think in th
Last time we DISCUSSed EOL of 1.1 was back in November. At that time, a
litany of issues were raised re: 1.2. Have those concerns been addressed?
It seems to me that making this one the last release is too abrupt to folks
tracking Apache. Would be better to give some notice.
Had a nice hallway con
> The discussion also brought up the notion of an LTS release line. I'm not
> sure how this jives with the more fequent minors, but would require some
> branch that's so stable that an RM can effectively spin releases blind.
Seems to me like this branch would necessarily need to be very
backport-l
One problem that I see is that it appears we are cutting branches extremely
early.
I'm going to pick on branch-1.4 for a moment. This branch has existed (as
far as I can remember) for at least 3-6 months, yet we still have not had a
1.4.0 release. I understand that releases can take time, but this
Amit Patel created HBASE-18539:
--
Summary: Remove usages of masterSystemTime
Key: HBASE-18539
URL: https://issues.apache.org/jira/browse/HBASE-18539
Project: HBase
Issue Type: Sub-task
On Tue, Aug 8, 2017 at 9:15 AM Mike Drob wrote:
> > The discussion also brought up the notion of an LTS release line. I'm not
> > sure how this jives with the more fequent minors, but would require some
> > branch that's so stable that an RM can effectively spin releases blind.
>
> Seems to me li
I made branch-1.4 a few weeks ago only. I did it because I had hoped to RC
quite quickly. Then the reality of compatibility breaks and failing unit
tests hit, as well as insufficient time for me to make progress on my
must-have for the release, which is a backport to RSGroups. I will get to
all of
+1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are candidates. I think
1.1 has the edge because it lacks locking changes introduced into 1.2, just
like 1.2 lacks locking changes introduced in 1.3 - the latter of which has
had far reaching consequences, and the former not an insignificant chang
> I made branch-1.4 a few weeks ago only.
Whoops, sorry for that! For some reason I thought I had seen it months ago.
On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell wrote:
> +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are candidates. I think
> 1.1 has the edge because it lacks locking
Well you are not wrong that branching was premature, it turns out. But I'll
roll with it...
On Tue, Aug 8, 2017 at 10:43 AM, Zach York
wrote:
> > I made branch-1.4 a few weeks ago only.
>
> Whoops, sorry for that! For some reason I thought I had seen it months ago.
>
> On Tue, Aug 8, 2017 at 10
Sean Busbey created HBASE-18540:
---
Summary: Ad-hoc job for checking if a test is flaky
Key: HBASE-18540
URL: https://issues.apache.org/jira/browse/HBASE-18540
Project: HBase
Issue Type: New Feat
[
https://issues.apache.org/jira/browse/HBASE-18530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-18530.
-
Resolution: Duplicate
hopefully I won't file this ticket again next week. ;p
> precommit should
Enis Soztutar created HBASE-18541:
-
Summary: [C++] Segfaults from JNI
Key: HBASE-18541
URL: https://issues.apache.org/jira/browse/HBASE-18541
Project: HBase
Issue Type: Sub-task
R
Appy created HBASE-18542:
Summary: [HLC] Performance microbenchmarks
Key: HBASE-18542
URL: https://issues.apache.org/jira/browse/HBASE-18542
Project: HBase
Issue Type: Sub-task
Reporter:
[
https://issues.apache.org/jira/browse/HBASE-18020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reopened HBASE-18020:
Does there need to be a documentation update too. This didn't work for me. On
branch-1.4
./d
Umesh Agashe created HBASE-18543:
Summary: master.TestMasterFailover fails on master
Key: HBASE-18543
URL: https://issues.apache.org/jira/browse/HBASE-18543
Project: HBase
Issue Type: Bug
Another option is no 1.5/branch-1 any more. What new features we are going
to have in HBase 1.5 (if it will be released)? Backporting from branch-2 to
branch-1 is not easy, so maybe we will not have any big feature in branch-1
after releasing 1.4. And if we release 1.5 after releasing 2.0, it may
c
Branch 2 doesn't have a release yet never mind enough production experience for
anyone other than bleeding edge to consider it. Some of us are rebasing
production on 1.x and once there intend for mid to long term stable operations.
So I think it is very likely we as a project will be maintaining
27 matches
Mail list logo
