+1 to "working toward semver". Is there any documentation that we would
like to clarify in the book given this enlightenment?
I would be in favor of going 2.6.0 and jackson upgrade in 1.1.
Enis
On Thu, Apr 23, 2015 at 5:34 PM, Nick Dimiduk wrote:
> On Thu, Apr 23, 2015 at 4:13 PM, Stack wrote
Andrew Purtell created HBASE-13552:
--
Summary: ChoreService shutdown message could be more informative
Key: HBASE-13552
URL: https://issues.apache.org/jira/browse/HBASE-13552
Project: HBase
I
Enis Soztutar created HBASE-13551:
-
Summary: Procedure V2 - Procedure classes should not be
InterfaceAudience.Public
Key: HBASE-13551
URL: https://issues.apache.org/jira/browse/HBASE-13551
Project: HB
On Thu, Apr 23, 2015 at 3:54 PM, Andrew Purtell wrote:
> Can we ask Hadoop to make a 2.5.3 release with HDFS-7005?
>
I have, and the offer is on the table.
https://issues.apache.org/jira/browse/HDFS-7005?focusedCommentId=14505636&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabp
On Thu, Apr 23, 2015 at 4:13 PM, Stack wrote:
> Does this 'admission' help with the which-hadoop thread too?
>
Right -- "working toward semver".
Are we now at liberty to bump to 2.6 or 2.7 even for branch-1.1? I still
have Karthik's offer to roll a 2.5.3 with the HDFS issue resolved.
What abou
+1 as well.
> On Apr 23, 2015, at 4:36 PM, Josh Elser wrote:
>
> Stack wrote:
>>> On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtell wrote:
>>>
>>> > So "we like semver", not "we use semver"?
>>> >
>>> >
>> and Sean's
>>
>>> > No longer claiming semver would also have the added benefit of m
Stack wrote:
On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtell wrote:
> So "we like semver", not "we use semver"?
>
>
and Sean's
> No longer claiming semver would also have the added benefit of making it for
me to easier to explain our compatibility promises to people.
Yeah, 'we like semv
Andrew Purtell created HBASE-13550:
--
Summary: [Shell] Support unset of a list of table attributes
Key: HBASE-13550
URL: https://issues.apache.org/jira/browse/HBASE-13550
Project: HBase
Issue
On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtell wrote:
> So "we like semver", not "we use semver"?
>
>
and Sean's
> No longer claiming semver would also have the added benefit of making it for
me to easier to explain our compatibility promises to people.
Yeah, 'we like semvar'/'we are almost se
I'd prefer a 2.6.1 or 2.7.1 over a 2.5.3 if we're asking hadoop to make
releases.
On Thu, Apr 23, 2015 at 4:00 PM, Sean Busbey wrote:
> On Thu, Apr 23, 2015 at 5:54 PM, Andrew Purtell
> wrote:
>
> > Can we ask Hadoop to make a 2.5.3 release with HDFS-7005?
> >
> > > What incompatibility is in 2
On Thu, Apr 23, 2015 at 5:08 PM, Andrew Purtell wrote:
> So "we like semver", not "we use semver"?
>
> Just want to make sure we're all on the same page (or find out if not).
>
>
+1 from me.
I'd prefer we not make the statements about binary compat for downgrading
because it's complicated and b
On Thu, Apr 23, 2015 at 5:54 PM, Andrew Purtell wrote:
> Can we ask Hadoop to make a 2.5.3 release with HDFS-7005?
>
> > What incompatibility is in 2.6.0
>
> This is a fair point. What's worse than HBASE-13149? which we hit with 2.5.
>
>
HBASE-13221, which I hit with HADOOP 2.6.0. It loses data,
On Thu, Apr 23, 2015 at 5:23 PM, Elliott Clark wrote:
> I just don't understand sticking with 2.5.1. Hadoop 2.5.1 is something
> that's basically un-usable in an environment with real load. I can't get it
> to pass 1/2 a day of IT tests ( which should mean that it fails all RC
> votes).
>
>
Wort
Can we ask Hadoop to make a 2.5.3 release with HDFS-7005?
> What incompatibility is in 2.6.0
This is a fair point. What's worse than HBASE-13149? which we hit with 2.5.
On Thu, Apr 23, 2015 at 3:23 PM, Elliott Clark wrote:
> I just don't understand sticking with 2.5.1. Hadoop 2.5.1 is somet
I just don't understand sticking with 2.5.1. Hadoop 2.5.1 is something
that's basically un-usable in an environment with real load. I can't get it
to pass 1/2 a day of IT tests ( which should mean that it fails all RC
votes).
The choice that we are giving the user:
* Upgrade to get bug fixes cri
> We also do it, so that users see less of "This was in 0.98, but how come
it is not in 1.0.x". I think we will get substantially better over time.
It will. Eventually we will EOL 0.98
In the meantime we could clarify how 0.98 relates to later releases now
that releases 1.0.0 and up are being mor
So "we like semver", not "we use semver"?
Just want to make sure we're all on the same page (or find out if not).
On Thu, Apr 23, 2015 at 2:59 PM, Enis Söztutar wrote:
> Then let's get Andrew's proposal committed:
>
> + APIs available in a patch version will be available in all later
> + patch
Then let's get Andrew's proposal committed:
+ APIs available in a patch version will be available in all later
+ patch versions. However, new APIs may be added which will not be
+ available in earlier patch versions.
I propose the following change to the "Client Binary compatibility" section
of S
On Thu, Apr 23, 2015 at 1:31 PM, Sean Busbey wrote:
> Why don't we just focus development after a minor release on the next minor
> release instead of the next patch release?
>
> We could limit backports to the patch releases to critical bugs, which
> would cut down on how often someone has to de
Sean Busbey created HBASE-13549:
---
Summary: metric for failed lease recovery
Key: HBASE-13549
URL: https://issues.apache.org/jira/browse/HBASE-13549
Project: HBase
Issue Type: Sub-task
Sean Busbey created HBASE-13548:
---
Summary: command for showing status of wal split tasks
Key: HBASE-13548
URL: https://issues.apache.org/jira/browse/HBASE-13548
Project: HBase
Issue Type: Sub-t
Sean Busbey created HBASE-13547:
---
Summary: metrics for wal splitting task handling
Key: HBASE-13547
URL: https://issues.apache.org/jira/browse/HBASE-13547
Project: HBase
Issue Type: Sub-task
Sean Busbey created HBASE-13546:
---
Summary: NPE on region server status page if all masters are down
Key: HBASE-13546
URL: https://issues.apache.org/jira/browse/HBASE-13546
Project: HBase
Issue
+1 (leaving 1.1 at Hadoop 2.5.x as is, and document how to use 2.6.x instead).
Note that I did not suggest going to 2.0 that in HBASE-13339, just that it
would be an option (after I said that forcing 2.6.0 in 1.1 would be a no-go,
IMHO).
-- Lars
From: Andrew Purtell
To: "dev@hbase.apache
On Thu, Apr 23, 2015 at 2:00 PM, Stack wrote:
> On Thu, Apr 23, 2015 at 12:03 PM, Andrew Purtell
> wrote:
>
> > That's fine but we still have unresolved problems:
> >
> > > Are the hadoop 2.5.x/2.6.x incompats just a few transitive includes
> > brought in by hadoop 2.6? Can we not release-note/d
I'm fine with us adding methods to public APIs in patch releases so long as
we stop claiming to follow semver. We can say we take the principles of
semver as inspiration. This would reflect the current state of the world
WRT 1.0.1 and would still give us a reason keep the narrower definition of
"ne
On Thu, Apr 23, 2015 at 12:03 PM, Andrew Purtell
wrote:
> That's fine but we still have unresolved problems:
>
> > Are the hadoop 2.5.x/2.6.x incompats just a few transitive includes
> brought in by hadoop 2.6? Can we not release-note/doc our way a semvar pass
> because our brothers upstream are
On Thu, Apr 23, 2015 at 11:23 AM, Enis Söztutar wrote:
> >
> >
> >
> > The presence of a 2.x so soon after 1.0 will cause 1.x to wither away (as
> > 0.96 was overshadowed by 0.98) and will confuse our users since it is
> ~98%
> > 1.0.0.
> >
>
> We should not forget that we are doing semver for th
I agree w/ the Enis characterization (so we need the callout on semvar) but
think we should practice what Seans says (patch is bug fixes only).
St.Ack
On Thu, Apr 23, 2015 at 1:31 PM, Sean Busbey wrote:
> Why don't we just focus development after a minor release on the next minor
> release inste
Enis Söztutar wrote:
+1 to the proposal.
The problem is that we have a very big API surface especially with the
coprocessors included in the report. Even simple bug fixes can introduce
protected or public methods to base classes, which makes patch releases
very hard to maintain. I would not want
Why don't we just focus development after a minor release on the next minor
release instead of the next patch release?
We could limit backports to the patch releases to critical bugs, which
would cut down on how often someone has to deal with the pain of making
sure we don't add to public APIs. It
[
https://issues.apache.org/jira/browse/HBASE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
churro morales resolved HBASE-13042.
Resolution: Fixed
> MR Job to export HFiles directly from an online cluster
> -
That's fine but we still have unresolved problems:
> Are the hadoop 2.5.x/2.6.x incompats just a few transitive includes
brought in by hadoop 2.6? Can we not release-note/doc our way a semvar pass
because our brothers upstream are less puritan than us? Heck, lets 'blame'
them!
We don't have a con
+1 to the proposal.
The problem is that we have a very big API surface especially with the
coprocessors included in the report. Even simple bug fixes can introduce
protected or public methods to base classes, which makes patch releases
very hard to maintain. I would not want to spend the effort to
No.
semver[1] has an explicit policy to have identifiers in this format:
MAJOR.MINOR.PATCH[-IDENTIFIER]
>From [1]:
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
Bullet point 9 in [1] talks about this. If we want to do "develope
I think it makes sense to continue to the other regions and eventually list out
the regions that couldn't be "fixed".
From: Stephen Jiang
Sent: Wednesday, April 22, 2015 3:52 PM
To: dev@hbase.apache.org
Subject: HBCK question: Exception in checkRegionConsi
>
>
>
> The presence of a 2.x so soon after 1.0 will cause 1.x to wither away (as
> 0.96 was overshadowed by 0.98) and will confuse our users since it is ~98%
> 1.0.0.
>
We should not forget that we are doing semver for the benefit of users. I
agree completely that
having 2.0 only 3-4 months after
On Thu, Apr 23, 2015 at 10:19 AM, Andrew Purtell
wrote:
> Let's postpone this vote.
>
Agreed.
>
> See the threads on dev@ titled "Clarifying interface evolution freedom in
> patch releases" and "The Renumbering (proposed)".
>
>
> On Wed, Apr 22, 2015 at 4:31 PM, Sean Busbey wrote:
>
> > On
On Thu, Apr 23, 2015 at 10:18 AM, Andrew Purtell
wrote:
> On HBASE-13339 (starting at
>
> https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507527#comment-14507527
> )
> there's an emerging consensus that we
Let's postpone this vote.
See the threads on dev@ titled "Clarifying interface evolution freedom in
patch releases" and "The Renumbering (proposed)".
On Wed, Apr 22, 2015 at 4:31 PM, Sean Busbey wrote:
> On Apr 22, 2015 4:40 PM, "Enis Söztutar" wrote:
> >
> > I think the agreement is to con
On HBASE-13339 (starting at
https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507527#comment-14507527)
there's an emerging consensus that we should renumber 1.1 as 2.0, so we can
move up to Hadoop 2.6.0 there w
Anyone disagree with the point of view put forward by Josh and Sean?
On Wed, Apr 22, 2015 at 10:35 AM, Josh Elser wrote:
> Andy -- I understood your intent, but thanks for clarifying. (as well as
> taking the time to break this discussion out in the first place). I agree
> with your assessment.
Jonathan Lawlor created HBASE-13544:
---
Summary: Provide better documentation for the public API
Scan#setMaxResultsPerColumnFamily
Key: HBASE-13544
URL: https://issues.apache.org/jira/browse/HBASE-13544
Jonathan Lawlor created HBASE-13545:
---
Summary: Provide better documentation for the public API
Scan#setRowOffsetPerColumnFamily
Key: HBASE-13545
URL: https://issues.apache.org/jira/browse/HBASE-13545
Jonathan Lawlor created HBASE-13543:
---
Summary: Deprecate Scan maxResultSize in 2.0.0
Key: HBASE-13543
URL: https://issues.apache.org/jira/browse/HBASE-13543
Project: HBase
Issue Type: Sub-t
Jonathan Lawlor created HBASE-13542:
---
Summary: Deprecate Scan batch in 2.0.0
Key: HBASE-13542
URL: https://issues.apache.org/jira/browse/HBASE-13542
Project: HBase
Issue Type: Sub-task
[
https://issues.apache.org/jira/browse/HBASE-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Lawlor resolved HBASE-13442.
-
Resolution: Duplicate
Closing this one in favor of HBASE-13541. Please reopen if there ar
Jonathan Lawlor created HBASE-13541:
---
Summary: Deprecate Scan caching in 2.0.0
Key: HBASE-13541
URL: https://issues.apache.org/jira/browse/HBASE-13541
Project: HBase
Issue Type: Sub-task
Sean Busbey created HBASE-13540:
---
Summary: better tooling for examining distributed work tasks
Key: HBASE-13540
URL: https://issues.apache.org/jira/browse/HBASE-13540
Project: HBase
Issue Type:
Sean Busbey created HBASE-13539:
---
Summary: Clean up empty WAL directories
Key: HBASE-13539
URL: https://issues.apache.org/jira/browse/HBASE-13539
Project: HBase
Issue Type: Bug
Compon
Sorry guys,
I'm know I'm very late in the process, but should we not release 1.2.0
instead of 1.1.0?
0.97 was for dev
0.99 was for dev
Should 1.1 be for dev too? Should we keep even numbers for prod releases
and odd for dev?
JM
2015-04-22 17:32 GMT-04:00 Enis Söztutar :
> I would love to see h
Srikanth Srungarapu created HBASE-13538:
---
Summary: Procedure v2 - client add/delete/modify column family sync
Key: HBASE-13538
URL: https://issues.apache.org/jira/browse/HBASE-13538
Project: HBas
Srikanth Srungarapu created HBASE-13537:
---
Summary: Change the admin interface for async operations to return
Future.
Key: HBASE-13537
URL: https://issues.apache.org/jira/browse/HBASE-13537
Proje
Srikanth Srungarapu created HBASE-13536:
---
Summary: Cleanup the handler that are no longer being used.
Key: HBASE-13536
URL: https://issues.apache.org/jira/browse/HBASE-13536
Project: HBase
54 matches
Mail list logo
