Whether any non-dev users are unable to move off 1.3, I suppose.
On Mon, Dec 2, 2019 at 11:04 AM Sean Busbey wrote:
> On what, specifically?
>
> On Mon, Dec 2, 2019, 11:24 Misty Linville wrote:
>
> > Should the user list be allowed to weigh in?
> >
> > On Mon,
Should the user list be allowed to weigh in?
On Mon, Dec 2, 2019 at 7:33 AM Andrew Purtell
wrote:
> I think there is a consensus on moving the stable pointer, based on
> earlier discussion. What I would suggest is a separate thread to propose
> it, and if nobody objects, do it.
>
> > On Dec 2,
Per-branch website / docs staging and publishing if the project wants it.
:) Other useful stuff below too.
-- Forwarded message -
From: Daniel Gruno
Date: Wed, Sep 4, 2019 at 5:33 PM
Subject: [NOTICE] Introducing .asf.yaml for enhanced automation of git
repository services
To:
+users@hbase, -users@infra to BCC
Thanks Duo for the great report and congratulations on such a successful
event.
On Tue, Aug 20, 2019 at 10:56 AM Stack wrote:
> Thanks for the writeup Duo. I added a synopsis here to the hbasecon
> archives (which should show up tonight after site build):
>
Each Apache project has a project management committee (PMC) that oversees
governance of the project, votes on new committers and PMC members, and
ensures that the software we produce adheres to the standards of the
Foundation. One of the roles on the PMC is the PMC chair. The PMC chair
represents
All,
HBase submits a report to the ASF board once a quarter, to inform the board
about project health. I'm sending the report to the user@ and dev@ mailing
lists because you are the project, and for transparency. If you have any
questions about the report or the running of the project, you can
Keeping artifacts and keeping build logs are two separate things. I don’t
see a need to keep any artifacts past the most recent green and most recent
red builds. Alternately if we need the artifacts let’s have Jenkins put
them somewhere rather than keeping them there. You can get back to whatever
quot;Release Notes" | wc
> -l
> >1
> > Busbey-MBA:hbase busbey$ git show cb0e9bb95599 | grep "Release Notes" |
> wc
> > -l
> > 1296
> > Busbey-MBA:hbase busbey$ git show 61e9de9b82a9 | grep "Release Notes" |
> wc
> >
NGES.txt
>
> HBase 2.0.0 had like 3 years of backlog fixes and the 2.0.5 summary of
> to date has 827KiB for CHANGES and 460KiB for RELEASENOTES.
>
> https://github.com/apache/hbase/blob/rel/2.0.5/CHANGES.md
> https://github.com/apache/hbase/blob/rel/2.0.5/RELEASENOTES.md
>
>
I’m confused how an automatically generated file can vary so much in size.
Can the release notes file with an archive just target the release in
question and leave off the older stuff? What’s the difference in practice
between the release noted and changelog?
A pre-commit and possibly a presubmit
I’ll review these by the end of the week unless anyone wants to jump in
sooner.
On Tue, May 28, 2019 at 8:59 AM Biju N wrote:
> Here are some simple ones (all documentation related issues). Hope these
> can be looked at quickly.
>
> https://issues.apache.org/jira/browse/HBASE-7129
>
Thank you for prioritizing the upgrade experience for the cautious
upgrader!
On Wed, Apr 24, 2019 at 6:38 AM 张铎(Duo Zhang) wrote:
> I think we'd better make a 2.0.6 release after 2.2.0 it out, and make sure
> that it is fine to upgrade to 2.2.0 from 2.0.6, and then EOL the 2.0.x
> release line.
For features, I think we would need to understand the popularity of a given
feature by our user base, and that might vary wildly by feature. Do you
think it would be possible to generalize?
On Wed, Apr 24, 2019 at 9:56 PM Stack wrote:
> On Wed, Apr 24, 2019 at 9:04 PM Yu Li wrote:
>
> > ...
>
I’m late on this, but I had this thought. Why not have a minimum
deprecation period of, say, 6 months, after which the API is eligible for
depreciation. At that point, a deprecation can be proposed on a DISCUSS
thread, with plenty of time given for discussion.
On Wed, Apr 24, 2019 at 9:56 PM
All,
HBase submits a report to the ASF board once a quarter, to inform the board
about project health. I'm sending the report to the user@ and dev@ mailing
lists because you are the project, and for transparency. If you have any
questions about the report or the running of the project, you can
+1 on renumbering.
On Wed, Apr 10, 2019 at 6:23 PM Andrew Purtell wrote:
> I am not anticipating a 1.5.1 release unless we need a patch release for
> some reason. After 1.5.0 will be 1.6.0.
>
> If we do need to make a 1.5.1 patch release, we can make a new branch from
> rel/1.5.0 named
Ah, I see. Thanks for explaining. That makes more sense!
On Fri, Apr 5, 2019 at 10:29 PM 张铎(Duo Zhang) wrote:
> Oh, Zheng Hu is a committer so he has the permission to merge... What I
> said is that, he should approve first before merging...
>
> Misty Linville 于2019年4月6日周六 下午1:19写
merge for PRs in the UI, but I think we did that already.
>
> On Fri, Apr 5, 2019 at 10:54 PM 张铎(Duo Zhang)
> wrote:
> >
> > IIRC we have filed an infra ticket to disable several operations related
> to
> > PR, and for merging, I think we should only allow committers to mer
Can we protect the GitHub branches from direct merges? That’s a repo-level
setting and we may not be able to change it. It seems potentially dangerous
for people to be able to merge their own changes especially if it only
takes one successful reviewer. Other communities use mechanisms like Prow
feature, bug, branch, module, etc). I have
> cycles
> > to burn but currently it feels a bit overwhelming as community may feel
> > there's a certain level of familiarity with the process necessary.
> >
> > On Wed, Mar 20, 2019, 4:59 AM Misty Linville wrote:
>
#1 this is difficult code. That’s probably the one we can’t surmount but I
wanted to put it out there.
On Tue, Mar 19, 2019 at 5:03 PM Sean Busbey wrote:
> I have my own opinions, obvs. But I'm curious what other folks think are
> the biggest impediments to new contributors?
>
xample:
>
> https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/client/HTable.html
>
> https://hbase.apache.org/0.94/devapidocs/org/apache/hadoop/hbase/client/HTable.html
>
> On Tue, Feb 5, 2019 at 3:58 AM Misty Linville wrote:
>
> > We should add rel=canonic
iduk wrote:
>
> > My only concern is that all my searches targeting our user guide land in
> > 0.94 docs. I don't know why the SEO lands us thusly, but I fear that
> > suddenly it'll look to user searches like the project is dead.
> >
> > On Mon, Feb 4
+1
On Mon, Feb 4, 2019 at 10:04 AM Stack wrote:
> Sounds good by me.
> S
>
> On Mon, Feb 4, 2019 at 7:40 AM Peter Somogyi wrote:
>
> > Does anyone have any concern with removing 0.94 documentation completely
> > from hbase.apache.org? Currently it is hosted at
> >
Andrew, maybe you can turn your ITBLL notes into docs in the reference
guide. There’s a whole section in there about testing.
On Sat, Feb 2, 2019 at 4:03 PM Andrew Purtell
wrote:
> Thanks. As I am not able to produce those unit test results we will need
> your help to diagnose the issues.
I think you may need to contact infra directly. I'm sorry you're facing
this trouble and I appreciate the extra effort you're going through to
contribute. I wonder if you can try creating a pull request on GitHub
instead of using Reviewboard until you get a resolution. I confess I am not
as
All,
HBase submits a report to the ASF board once a quarter, to inform the board
about project health. I'm sending the report to the user@ and dev@ mailing
lists because you are the project, and for transparency. If you have any
questions about the report or the running of the project, you can
+1 What needs to happen next?
On Fri, Dec 7, 2018, 9:03 AM Sean Busbey Hi folks!
>
> Per the email from infra "[NOTICE] Mandatory relocation of Apache git
> repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe ) it
> looks like the future of interacting directly with PRs is coming
Zhang) I think it is fine to keep the current implementation? What is the problem
> if we schedule in reverse order? We do not guarantee any order when
> executing the sub procedures...
>
> Misty Linville 于2018年12月1日周六 下午1:56写道：
>
> > I like your solution in principle,
I like your solution in principle, but I think it would be better to loop
until the queue reports that it's empty.
On Wed, Nov 28, 2018, 8:18 PM OpenInx Thanks Allan's reply
>
> So if we can ensure that all children are independent, then it won't be a
> problem.
> But the reversed shcedule order
Thanks for your continuing and increasing commitment to the project and the
community!
On Wed, Oct 17, 2018, 11:14 PM OpenInx Congratulations Zach!
>
> On Wed, Oct 17, 2018 at 8:14 PM ramkrishna vasudevan <
> ramkrishna.s.vasude...@gmail.com> wrote:
>
> > Congratulations Zach!!!
> >
> > On Wed,
Congratulations, and thanks for opting to spend more time making HBase the
software and the project better!
On Wed, Nov 14, 2018, 3:26 AM Anoop John Congrats Jingyun !!!
>
> -Anoop-
>
> On Wed, Nov 14, 2018 at 8:18 AM Jingyun Tian wrote:
>
> > Thank you all!
> >
> > Sincerely,
> > Jingyun Tian
When discussing the 2.0.x branch in another thread, it came up that we
don’t have a good way to understand the version skew of HBase across the
user base. Metrics gathering can be tricky. You don’t want to capture
personally identifiable information (PII) and you need to be transparent
about what
I’ll start another thread about metrics gathering.
On Tue, Nov 13, 2018 at 8:15 AM Stack wrote:
> On Sun, Nov 11, 2018 at 8:18 PM Misty Linville wrote:
>
> > It's not great to guess about things like this.
> > We're making a big assumption that our users actually pay att
This makes me wonder if we have, or have a way to get, analytics about the
version people are running? It's not great to guess about things like this.
We're making a big assumption that our users actually pay attention to user@
or more often dev@ in order to complain about a branch being retired
I'll review this JIRA this weekend if you add me as a reviewer.
On Fri, Oct 19, 2018, 12:35 PM Andrew Purtell wrote:
> https://issues.apache.org/jira/browse/HBASE-21346
>
> On Fri, Oct 19, 2018 at 12:29 PM Andrew Purtell
> wrote:
>
> > Roger that, try this, push, and pray. Thanks Mike.
> >
> >
All,
HBase submits a report to the ASF board once a quarter, to inform the board
about project health. I'm sending the report to the user@ and dev@ mailing
lists because you are the project. If you have any questions about the
report or the running of the project, you can pose them to me or any
isk of
> disappearing magically?
>
> I'm pretty sure all of the HBaseCon content only exists in the
> hbase-site.git repository.
>
> Thanks Misty.
>
> On 9/17/18 3:12 PM, Misty Linville wrote:
> > Then it will get clobbered the next time the site is built by CI. Please
Then it will get clobbered the next time the site is built by CI. Please
update it in the main master.
On Mon, Sep 17, 2018, 10:01 AM Josh Elser wrote:
> Any chance you can open up a Jira issue and provide a patch to update
> hbase-site.git?
>
>
Misty Linville created HBASE-21184:
--
Summary: Update site-wide references from http to https
Key: HBASE-21184
URL: https://issues.apache.org/jira/browse/HBASE-21184
Project: HBase
Issue
on Go, but others pointed me there.
On Tue, Sep 4, 2018 at 4:12 PM, Misty Linville wrote:
> Here's the code to the bot: https://github.com/kubernetes/test-infra/tree/
> master/robots/commenter
>
> On Tue, Sep 4, 2018 at 10:21 AM, Sean Busbey wrote:
>
>> Do you have
Here's the code to the bot:
https://github.com/kubernetes/test-infra/tree/master/robots/commenter
On Tue, Sep 4, 2018 at 10:21 AM, Sean Busbey wrote:
> Do you have a link to an instance of the bot you're talking about?
> On Tue, Sep 4, 2018 at 11:18 AM Misty Linville wrote:
> >
&
The below snip isn't true. Somehow CNCF has tooling that does it (it is a
bot called fejtabot). I can try to find out more about it if this is a
mechanism we are interested in pursuing.
On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey wrote:
>
>
> We can't automate closing PRs because the only way to
I like this suggestion, Yu, along with enthusiastic closing of GitHub PRs
that don't follow the established procedures. Could we create an automated
test for such compliance, like scanning the PR comments for specific text?
CNCF projects use automation to parse a specific syntax in comments and
I'm concerned that getting the logs will take a lot of your time. Is there
a way to have the automation put them somewhere where the patch author can
get to them when needed? Also how much time will this take to set up? Will
it be worth it? Will this initial setup be useful long-term in any way?
To be clear, I'm good with a symbolic representation, but I think we should
be making positive statements about configs we stand behind rather than
those we don't. More of a bounded set.
On Tue, Aug 21, 2018, 11:01 AM Misty Linville wrote:
> Let's change that table to positive stateme
Let's change that table to positive statements. Production, supported,
recommended, tested. WDYT?
On Tue, Aug 21, 2018, 8:12 AM Josh Elser wrote:
> Mich T had cross-posted a question to users@{hbase,phoenix} the only
> day. After some more information, we were able to find out that Mich was
>
Is GitHub integration going to make patch review more palatable and
efficient for reviewers? Maybe we can increase our roster of regular
reviewers by using GitHub.
We can make a bot that looks for things in PR comment text. That way you
could add the JIRA number in a way the bit can pick it up
Congratulations to you and all involved in organizing this successful
event, Yu Li! Thank you for your leadership.
It would be great if any attendees on these lists would to share their
experiences from event. It's awesome to see the growth of the HBase
community in Asia.
Misty
On Mon, Aug 20,
Thanks for the report and for attending, and thanks to everyone who made
HbaseCon Asia 2018 and the dev meet-up happen!
On Sun, Aug 19, 2018, 3:50 AM Stack wrote:
> There were about 30 of us. I didn't take roll. See photos below [1][2].
> PMCers, committers, contributors, and speakers from the
I wouldn't offer them email as a way to communicate about releases. Maybe
JIRA or the list. Though I think JIRA is best.
On Wed, Aug 15, 2018, 12:16 PM Sean Busbey wrote:
> If anyone has feedback before I send this, please let me know. I've
> already updated dist.a.o for the stable line change.
I like the idea of a separate connectors repo/release vehicle, but I'm a
little concerned about the need to release all together to update just one
of the connectors. How would that work? What kind of compatibility
guarantees are we signing up for?
On Tue, Jul 24, 2018, 9:41 PM Stack wrote:
>
In addition to the build problems probably caused by a lack of Jenkins
workers, there is a bug in the script somewhere that causes the git hash of
the commit that failed to build not to be expanded. I'm not going to be on
a computer all weekend so can someone file and / or investigate?
On Jul 21,
All,
I'd like to give you the opportunity to state your pronouns, for inclusion
in the project POM and the members list. *This is completely optional.*
If you'd like your pronouns to be listed, please fill out this survey:
All,
HBase submits a report to the ASF board once a quarter, to inform the board
about project health. I'm sending the report to the user@ and dev@ mailing
lists because you are the project, and for transparency. If you have any
questions about the report or the running of the project, you can
55 matches
Mail list logo
