Re: Re: Nice article on one of our own....
Thanks all and thanks the HBase community. Justin Ling Mao 于2019年1月10日周四 上午11:37写道： > Duo is the model worker of ASF. well deserved !!! > - 原始邮件 - > 发件人：Andrew Purtell > 收件人：dev@hbase.apache.org > 主题：Re: Nice article on one of our own > 日期：2019年01月10日 11点32分 > > > Kudos to you Duo, well deserved. > > On Jan 9, 2019, at 6:24 PM, Yu Li wrote: > > > > Wow! Great job and thank you, Duo! > > > > And I like the "something few people knew about you" part (smile) > > > > Best Regards, > > Yu > > > > > >> On Thu, 10 Jan 2019 at 07:11, Sean Busbey wrote: > >> > >> it's a charming profile, Duo! > >> > >>> On Wed, Jan 9, 2019 at 12:42 PM Stack wrote: > >>> > >>> See #3 in list of top 5 Apache committers: > >>> https://www.cbronline.com/feature/apache-top-5 > >>> S > >> >
回复：Re: Nice article on one of our own....
Duo is the model worker of ASF. well deserved !!! - 原始邮件 - 发件人：Andrew Purtell 收件人：dev@hbase.apache.org 主题：Re: Nice article on one of our own 日期：2019年01月10日 11点32分 Kudos to you Duo, well deserved. > On Jan 9, 2019, at 6:24 PM, Yu Li wrote: > > Wow! Great job and thank you, Duo! > > And I like the "something few people knew about you" part (smile) > > Best Regards, > Yu > > >> On Thu, 10 Jan 2019 at 07:11, Sean Busbey wrote: >> >> it's a charming profile, Duo! >> >>> On Wed, Jan 9, 2019 at 12:42 PM Stack wrote: >>> >>> See #3 in list of top 5 Apache committers: >>> https://www.cbronline.com/feature/apache-top-5 >>> S >>
Re: Nice article on one of our own....
Kudos to you Duo, well deserved. > On Jan 9, 2019, at 6:24 PM, Yu Li wrote: > > Wow! Great job and thank you, Duo! > > And I like the "something few people knew about you" part (smile) > > Best Regards, > Yu > > >> On Thu, 10 Jan 2019 at 07:11, Sean Busbey wrote: >> >> it's a charming profile, Duo! >> >>> On Wed, Jan 9, 2019 at 12:42 PM Stack wrote: >>> >>> See #3 in list of top 5 Apache committers: >>> https://www.cbronline.com/feature/apache-top-5 >>> S >>
HBase quarterly report Oct-Dec 2018
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 pose them to me or any other PMC member or committer, or send an email to priv...@hbase.apache.org, which every PMC member subscribes to. Thanks, Misty -- ## Description: Apache HBase is an open-source, distributed, versioned, non-relational database. Apache HBase gives you low latency random access to billions of rows with millions of columns atop non-specialized hardware. hbase-thirdparty is a set of internal artifacts used by the project to mitigate the impact of our dependency choices on the wider ecosystem. ## Issues: Board-only information removed from public report. ## Activity: There have been lots of interesting discussions on the dev@ mailing list. Highlights: - Discussion is ongoing about plans to move to Gitbox and ways the project can accommodate users who prefer to contribute using Github. ( https://lists.apache.org/thread.html/3496568d6cc002f74f5c3bcce46ed44b7ee9e90d7d53af2c65b6f785@%3Cdev.hbase.apache.org%3E ) - An interesting discussion occurred about the frequency of releases in the 2.1.x line ( https://lists.apache.org/thread.html/222aacbf74d9788287ef5606fe66a06c1a3aa31a299a469d124a5ee0@%3Cdev.hbase.apache.org%3E). The discussion included a sub-discussion about what it will take to separate the hbck took from the main project, and another sub-discussion about time-based releases and release cadence in general. It's worth a read. - A proposal to retire the 1.3 line resulted in Francis Liu stepping in to be the release manage for the line, because his team relies on that branch. Francis is aiming for a quarterly release cadence. In the same discussion, Andrew Purtell and Sean Busbey discuss how they have been managing 1.2 and 1.4 lines, and plans for the 1.5 line. ( https://lists.apache.org/thread.html/dd655a21cb5eb23a983648d71f5d08ca567b110ab9128a70f06eddcc@%3Cdev.hbase.apache.org%3E ) - Another discussion of 1.x release cadences was started by Andrew Purtell, including specific plans for the 1.5 branch. ( https://lists.apache.org/thread.html/e18266c8aa1e1406f3e652a3a1ee52d498aaad506537621cc754499b@%3Cdev.hbase.apache.org%3E ) - Another interesting discussion resulted in improved understanding and documentation of the process for editing and rebuilding pages on the HBase website that don't result from building the documentation. ( https://lists.apache.org/thread.html/18010d0897752db7f9d91f4f75694831a7ed9db28739ce4a91e546e4@%3Cdev.hbase.apache.org%3E ) - Speaking of 1.5, the first snapshot is available for testing. ( https://lists.apache.org/thread.html/bbf7b47920da532535bb8ce493df3265fd91211b227f681b2cc3c3a2@%3Cdev.hbase.apache.org%3E ) Josh Elser started a discussion on the PMC list about the definition of and parameters for an HBaseCon event, who can run one, and other guidelines, informed by his work organizing HBaseCon US 2018. He's working on some project-facing documentation, which promises to be helpful for future organizers of HBase-related events worldwide. The HBase project is working toward the goal of more frequent minor releases and fewer unprompted maintenance releases. In total this quarter, HBase had 8 releases over this quarter, across 5 release lines. Another goal, spanning several quarters, is to solicit more non-binding votes on release candidates, as non-binding votes are one signal of broader community engagement. Here are a few examples: - HBase 1.3.3 RC0 had 40% non-binding votes ( https://lists.apache.org/thread.html/9e3a472e142faa9a48ed5ab0e1e1baaaeb9ddfe7a9fdcfa547c2cd20@%3Cdev.hbase.apache.org%3E ) - HBase 1.4.8 RC0 had 50% non-binding votes ( https://lists.apache.org/thread.html/2f8ad79f6da4d2ac223a61b82aeb29a2322479257f271da90f0687e0@%3Cdev.hbase.apache.org%3E ) - HBase 2.1.1 RC0 also had 50% non-binding votes ( https://lists.apache.org/thread.html/f9ccc377dbeac4b3a7a0cddcef0cd7369675f5b1cc570b6c19a52864@%3Cdev.hbase.apache.org%3E ) As a reminder, anyone on the dev@ list can test and provide feedback on a release candidate, and cast a non-binding vote. Lars Hofhansl is in the process of organizing a bay-area HBase developer meet-up at Salesforce. If you're interested, participate in the thread. ( https://lists.apache.org/thread.html/e814054e8d8ad1c5ebb30b9c50d97b5b8b5edada121f184fdf045e3d@%3Cdev.hbase.apache.org%3E ) Two new committers were added this quarter, and two committers joined the PMC. More details below. Thanks to the new committers and PMC members for agreeing to take on more responsibilities in the project. ## Health report: Despite a slow holiday quarter, the HBase project shows a high level of engagement, as seen through release cadence, deep and meaningful discussion on mailing lists, discussion and documentation of processes, and
Re: Nice article on one of our own....
Wow! Great job and thank you, Duo! And I like the "something few people knew about you" part (smile) Best Regards, Yu On Thu, 10 Jan 2019 at 07:11, Sean Busbey wrote: > it's a charming profile, Duo! > > On Wed, Jan 9, 2019 at 12:42 PM Stack wrote: > > > > See #3 in list of top 5 Apache committers: > > https://www.cbronline.com/feature/apache-top-5 > > S >
Re: Nice article on one of our own....
Nice job, Duo! Best Regards Allan Yang Guanghao Zhang 于2019年1月10日周四 上午10:26写道： > Congratulations! > > Reid Chan 于2019年1月10日周四 上午10:24写道： > > > Thumbs up & clap! > > > > > > > > > > -- > > > > Best regards, > > R.C > > > > > > > > > > > > > > From: Stack > > Sent: 10 January 2019 02:41 > > To: HBase Dev List > > Subject: Nice article on one of our own > > > > See #3 in list of top 5 Apache committers: > > https://www.cbronline.com/feature/apache-top-5 > > S > > >
Re: Nice article on one of our own....
Congratulations! Reid Chan 于2019年1月10日周四 上午10:24写道： > Thumbs up & clap! > > > > > -- > > Best regards, > R.C > > > > > > > From: Stack > Sent: 10 January 2019 02:41 > To: HBase Dev List > Subject: Nice article on one of our own > > See #3 in list of top 5 Apache committers: > https://www.cbronline.com/feature/apache-top-5 > S >
Re: Nice article on one of our own....
Thumbs up & clap! -- Best regards, R.C From: Stack Sent: 10 January 2019 02:41 To: HBase Dev List Subject: Nice article on one of our own See #3 in list of top 5 Apache committers: https://www.cbronline.com/feature/apache-top-5 S
Re: Nice article on one of our own....
it's a charming profile, Duo! On Wed, Jan 9, 2019 at 12:42 PM Stack wrote: > > See #3 in list of top 5 Apache committers: > https://www.cbronline.com/feature/apache-top-5 > S
Re: Nice article on one of our own....
Congratulations and thank you, Duo, for all your efforts! On Wed, Jan 9, 2019 at 10:42 AM Stack wrote: > See #3 in list of top 5 Apache committers: > https://www.cbronline.com/feature/apache-top-5 > S >
[jira] [Reopened] (HBASE-21685) Change repository urls to Gitbox
[ https://issues.apache.org/jira/browse/HBASE-21685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reopened HBASE-21685: - the job succeeded but the website hasn't updated and github/apache/hbase-site doesn't reflect the commits the job claims it pushed. reopening while I check on what's up > Change repository urls to Gitbox > > > Key: HBASE-21685 > URL: https://issues.apache.org/jira/browse/HBASE-21685 > Project: HBase > Issue Type: Task >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0 > > Attachments: HBASE-21685.master.001.patch, > HBASE-21685.master.001.patch > > > Moving to Gitbox is approaching and references to git-wip-us need to be > changed to gitbox. > Some of the Jenkins jobs are referring to git-wip-us which if going to be > locked after the migration. We could move them to github so the build flow > will remain intact. > Previous discussion on dev@: > [https://lists.apache.org/thread.html/3496568d6cc002f74f5c3bcce46ed44b7ee9e90d7d53af2c65b6f785@%3Cdev.hbase.apache.org%3E] > After this notify INFRA to make the change -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21556) Create 2.1.2 release
[ https://issues.apache.org/jira/browse/HBASE-21556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-21556. --- Resolution: Fixed Fix Version/s: 2.1.2 Sent the announce email. Resolving. > Create 2.1.2 release > > > Key: HBASE-21556 > URL: https://issues.apache.org/jira/browse/HBASE-21556 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.1.2 > > Attachments: Screen Shot 2018-12-05 at 8.38.32 PM.png > > > Roll new 2.1 because of memory leak. See HBASE-21551 > 2.1 is doing not too bad. 3 of last 5 passed. > !Screen Shot 2018-12-05 at 8.38.32 PM.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Nice article on one of our own....
See #3 in list of top 5 Apache committers: https://www.cbronline.com/feature/apache-top-5 S
[NOTICE] project repository URLs have changed
Hi folks! Our project has now transitioned from the old "git-wip" process to the current ASF infra preferred "gitbox" repository hosting[1]. The main practical impact for most folks day-to-day is that you will need to update your git remote url[2]; this is true both for contributors who want to see up to date changes as well as committers who wish to push changes. tl;dr: git remote set-url origin https://gitbox.apache.org/repos/asf/hbase.git This presumes that you are in the working directory of your git checkout and that you refer to the main repo as the default remote name "origin". Out of the box, this repository URL should be set to work with the same credentials, if any, you previously used to interact with the old git-wip repository. You should be able to both fetch and push as you have previously done. Note that under the gitbox service it is possible for committers to enable write access to the GitHub repository[3]. By doing so a committer could work directly with the GitHub PR interface instead of doing so indirectly as we have historically done. We have an ongoing discussion and documentation effort for how we as a community want to handle that work[4]. I'd ask that interested folks participate in said discussion and everyone hold off using our new write access to GitHub until we've documented the consensus position. The changes also impact our "hbase-site" and "hbase-thirdparty" repositories. The gitbox URLs for those repositories are analogous to the one I gave above for the main repo. There is no change to the "hbase-operator-tools" repository, as it has always been on the gitbox service. If you notice an automated process break and it looks related to git, please ping myself and/or Peter Somogyi and we'll help fix any fallout from this transition. -busbey [1]: ASF Infra is decommissioning the "git-wip" project and has required all projects move to the gitbox service. There's more explanation in the thread "[DISCUSS] move to gitbox" https://s.apache.org/lUHS [2]: This isn't true if you already use a remote that points at github. That repository should continue to see updates. [3]: After enabling a sync between your ASF identity and your GitHub identity, the GitHub repo is writable. Committers have "maintainer" access and can both configure the repository settings and push commits directly to GitHub. https://gitbox.apache.org/setup/ [4]: HBASE-21701 'Accept pull requests from contributors'
Re: Rolling 2.1.2 and 2.0.4
To close out this thread, 2.1.2 and 2.0.4 have been released to replace 2.1.1 and 2.0.3. Thew new releases include fixes for the damaging HBASE-21551. Thanks, S On Wed, Dec 5, 2018 at 8:03 PM Stack wrote: > 2.1.1 and 2.0.3 have an ugly bug found by our Zheng Hu. See HBASE-21551 > Memory leak when use scan with STREAM at server side. > > S >
[ANNOUNCE] Apache HBase 2.1.2 is now available for download
The HBase team is happy to announce the immediate availability of Apache HBase 2.1.2. Download from https://hbase.apache.org/downloads.html Apache HBase is an open-source, distributed, versioned, non-relational database. Apache HBase gives you low latency random access to billions of rows with millions of columns atop non-specialized hardware. To learn more about HBase, see https://hbase.apache.org/. HBase 2.1.2 is the latest release of the HBase 2.1 line, continuing on the theme of bringing a stable, reliable database to the Apache Big Data ecosystem and beyond. It fixes a critical issue found in the recent 2.1.1 and 2.0.3 releases (only), HBASE-21551. 2.1.2 includes ~70 bug and improvement fixes done since the 2.1.1, released ~ two months ago. For instructions on verifying ASF release downloads, please see https://www.apache.org/dyn/closer.cgi#verify Project member signature keys can be found at https://www.apache.org/dist/hbase/KEYS Thanks to all the contributors who made this release possible! Best, The HBase Dev Team
Re: [DISCUSS] move to gitbox
sure thing. let me draft it up now. On Wed, Jan 9, 2019 at 11:29 AM Andrew Purtell wrote: > According to the ticket the main repo and third-party repo have been > migrated. We are just waiting on site. > > I'd appreciate it if we can send out that email now, because I'd like to > continue commiting toward 1.5.0. At least, a pointer to docs on how the > integration functions and the steps a committer needs to take to push and > pull changes would be appreciated. > > > > On Jan 9, 2019, at 8:56 AM, Sean Busbey wrote: > > > > I filed a ticket with INFRA: > > > > https://issues.apache.org/jira/browse/INFRA-17597 > > > > The actual transition is supposed to only take a few minutes. Once it's > done we should send a NOTICE email to dev@hbase summarizing what has > changed and what folks will need to do different. > > > > > > > >> On 2019/01/08 19:07:30, Peter Somogyi wrote: > >> I believe we reached consensus to migrate our remaining repositories to > >> GitBox before the mandatory migration which will happen on 7th of > February. > >> Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty' > >> repositories that also require the same migration process. > >> > >> From users' point of view they could still use git:// > >> git.apache.org/hbase.git for read only access, only committers need to > >> change the remote URL to the GitBox one. Jenkins jobs are already using > the > >> GitHub URL for cloning the repository and I created a patch for the > >> documentation and website changes in HBASE-21685 that we can merge after > >> the process is competed. > >> > >> There's still outstanding work to do before we have good guidelines on > >> accepting pull requests on GitHub, but the GitBox migration doesn't > require > >> our committers to start working with PRs in a different way. > >> > >> If there is no disagreement I'd kindly ask one of the PMC members to > reach > >> out to INFRA to perform the migration. > >> > >> Thanks, > >> Peter > >> > >> On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell < > andrew.purt...@gmail.com> > >> wrote: > >> > >>> Sounds good to me except squash merge at commit of PR shouldn’t be an > >>> option it should be required except for good reason (and I don’t know > what > >>> that would be ) > >>> > > On Dec 8, 2018, at 3:28 PM, Stack wrote: > > > > On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey > wrote: > > > > The move to gitbox doesn't require us to only accept github PRs. > Given > > the current rate of contributions via patches on JIRA vs GitHub PRs, > I > > wouldn't want to push for that now. > > > > The change does make it easier for us to start encouraging PR > > submissions, because committers will be able to directly merge from > > the GitHub UI. > > > > I'd recommend we try to keep this as a small incremental change. That > > would mean: > > > > * committers ensure there's an associated JIRA for release note and > > precommit checks (that can be just by pinging the contributor to go > > make one) > > * backports are still handled by the committer if they're simple and > > the contributor if there's a problem. I think saying "open a new PR > to > > backport to branch FOO" is perfectly reasonable since it's analogous > > to when we ask contributors to attach a branch specific patch. > > * committers ensure the pushed commit has a message that follows our > > current practice (which would mean looking out for the "helpful" > > subject wrapping) > > * Squash merge is an option when the committer goes to accept the PR. > > the contributor is free to either push additional commits or squash > on > > their branch when working through reviews, I don't think we need to > > weigh in on how contributors choose which of those works best for > > them. > > > > That way we can also incrementally improve how well we handle PR > > submissions by better documenting expectations and building up > > additional tooling (e.g. having our precommit feedback go directly to > > the PR instead of being tied to a JIRA) > > > > This seems reasonable to me. Andrew's strawman would be too radical a > change. > Thanks, > S > > > >>> On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: > >>> > >>> On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey > wrote: > >>> > >>> 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 > >>> sooner > >>> rather than later. > >>> > >>> I think we should move to gitbox ASAP rather than wait for the > crunch. > > If > >>> we hit a rough spot we're more likely to get some help when things > > aren't > >>> busy. Maybe we wait until our open RCs
Re: [VOTE] First release candidate for HBase 1.2.10 is available
+1 - Signatures, checksums: OK - Built from source (8u112): OK - Unit tests: OK - LTT with 1M rows: OK - Basic shell commands: OK - Web UI: OK I also hit HBASE-21687 with maven 3.6. On Wed, Jan 9, 2019 at 12:36 AM Andrew Purtell wrote: > +1 (binding) > > Checked sums and signatures: ok > Built from source*: ok (7u80) > RAT check passed: ok (7u80) > Unit tests pass: ok (7u80) > LTT load 1M rows: ok (8u172) > > * - HBASE-21687 is needed on top of the RC for the build to complete with > Maven 3.6. > > > On Mon, Jan 7, 2019 at 5:51 PM Sean Busbey wrote: > > > The first release candidate for HBase 1.2.10 is available for download: > > > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.10RC0/ > > > > Maven artifacts are also available in a staging repository at: > > > > https://repository.apache.org/content/repositories/orgapachehbase-1249/ > > > > Artifacts are signed with my key (0D80DB7C) published in our KEYS > > file at http://www.apache.org/dist/hbase/KEYS > > > > The RC corresponds to the signed tag 1.2.10RC0, which currently points > > to commit ref > > > > 18f428abb64b405de24d164425e470512e82f287 > > > > HBase 1.2.10 is the tenth maintenance release in the HBase 1.2 line, > > continuing on the theme of bringing a stable, reliable database to > > the Hadoop and NoSQL communities. This release includes about a half > > dozen bug fixes done in the month since 1.2.9. > > > > The detailed source and binary compatibility report vs 1.2.9 has been > > published for your review, at: > > > > https://s.apache.org/hbase-1.2.10-rc0-compat-report > > > > The report shows some issues with two IA.LimitedPrivate classes annotated > > for use in TOOLS and CONFIG, as well as a false positive incompatibility > > for > > the WALCellCodec class. > > > > Critical fixes include: > > > > * HBASE-21387 - Race condition surrounding in progress snapshot handling > in > > snapshot cache leads to loss of snapshot files > > * HBASE-21492 - CellCodec Written To WAL Before It's Verified > > * HBASE-21504 - If enable FIFOCompactionPolicy, a compaction may write a > > "empty" hfile whose maxTimeStamp is long max. This kind > of > > hfile will never be archived. > > * HBASE-21582 - If call HBaseAdmin#snapshotAsync but forget call > > isSnapshotFinished, then SnapshotHFileCleaner will skip > to > > run every time > > > > The full list of fixes included in this release is available at: > > > > https://s.apache.org/hbase-1.2.10-jira-release-notes > > > > and in the CHANGES.txt file included in the distribution. > > > > Please try out this candidate and vote +1/-1 on whether we should > > release these artifacts as HBase 1.2.10. > > > > The VOTE will remain open for at least 72 hours. Given sufficient votes > > I would like to close it on January 11th, 2019. > > > > thanks! > > > > -busbey > > > > as of this email the posted artifacts have the following SHA512: > > > > hbase-1.2.10-src.tar.gz: > > D800AEEC 1F6B448D 33C15C5A EA5ECE2E 965C82F1 C68DA586 > > BA6DB8A7 471573A7 09434016 2E5A14C0 87EF188A 365A4009 > > 3F726587 21F85D4A 57DA50F1 E940EEE6 > > > > hbase-1.2.10-bin.tar.gz: > > BA085D9E 0EBC67FC E37A4F47 02C98EB0 2EFEF8BE 81AE4388 > > 16A0CC4A 6614788A 4CBF0ABE 47F02C85 ECF4C20E 89343417 > > F2A80FD8 B80481D0 DD2B844B 580D143F > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
Re: [DISCUSS] move to gitbox
According to the ticket the main repo and third-party repo have been migrated. We are just waiting on site. I'd appreciate it if we can send out that email now, because I'd like to continue commiting toward 1.5.0. At least, a pointer to docs on how the integration functions and the steps a committer needs to take to push and pull changes would be appreciated. > On Jan 9, 2019, at 8:56 AM, Sean Busbey wrote: > > I filed a ticket with INFRA: > > https://issues.apache.org/jira/browse/INFRA-17597 > > The actual transition is supposed to only take a few minutes. Once it's done > we should send a NOTICE email to dev@hbase summarizing what has changed and > what folks will need to do different. > > > >> On 2019/01/08 19:07:30, Peter Somogyi wrote: >> I believe we reached consensus to migrate our remaining repositories to >> GitBox before the mandatory migration which will happen on 7th of February. >> Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty' >> repositories that also require the same migration process. >> >> From users' point of view they could still use git:// >> git.apache.org/hbase.git for read only access, only committers need to >> change the remote URL to the GitBox one. Jenkins jobs are already using the >> GitHub URL for cloning the repository and I created a patch for the >> documentation and website changes in HBASE-21685 that we can merge after >> the process is competed. >> >> There's still outstanding work to do before we have good guidelines on >> accepting pull requests on GitHub, but the GitBox migration doesn't require >> our committers to start working with PRs in a different way. >> >> If there is no disagreement I'd kindly ask one of the PMC members to reach >> out to INFRA to perform the migration. >> >> Thanks, >> Peter >> >> On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell >> wrote: >> >>> Sounds good to me except squash merge at commit of PR shouldn’t be an >>> option it should be required except for good reason (and I don’t know what >>> that would be ) >>> > On Dec 8, 2018, at 3:28 PM, Stack wrote: > > On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote: > > The move to gitbox doesn't require us to only accept github PRs. Given > the current rate of contributions via patches on JIRA vs GitHub PRs, I > wouldn't want to push for that now. > > The change does make it easier for us to start encouraging PR > submissions, because committers will be able to directly merge from > the GitHub UI. > > I'd recommend we try to keep this as a small incremental change. That > would mean: > > * committers ensure there's an associated JIRA for release note and > precommit checks (that can be just by pinging the contributor to go > make one) > * backports are still handled by the committer if they're simple and > the contributor if there's a problem. I think saying "open a new PR to > backport to branch FOO" is perfectly reasonable since it's analogous > to when we ask contributors to attach a branch specific patch. > * committers ensure the pushed commit has a message that follows our > current practice (which would mean looking out for the "helpful" > subject wrapping) > * Squash merge is an option when the committer goes to accept the PR. > the contributor is free to either push additional commits or squash on > their branch when working through reviews, I don't think we need to > weigh in on how contributors choose which of those works best for > them. > > That way we can also incrementally improve how well we handle PR > submissions by better documenting expectations and building up > additional tooling (e.g. having our precommit feedback go directly to > the PR instead of being tied to a JIRA) > This seems reasonable to me. Andrew's strawman would be too radical a change. Thanks, S >>> On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: >>> >>> On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey wrote: >>> >>> 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 >>> sooner >>> rather than later. >>> >>> I think we should move to gitbox ASAP rather than wait for the crunch. > If >>> we hit a rough spot we're more likely to get some help when things > aren't >>> busy. Maybe we wait until our open RCs close so that folks that need > to tag >>> those releases don't need to update their workflow first? >>> >>> Presuming everyone still agrees that we get value out of JIRA, I think > we >>> need update our committer guidelines to expressly remind folks to > check on >>> things like commit messages
Re: [DISCUSS] move to gitbox
I filed a ticket with INFRA: https://issues.apache.org/jira/browse/INFRA-17597 The actual transition is supposed to only take a few minutes. Once it's done we should send a NOTICE email to dev@hbase summarizing what has changed and what folks will need to do different. On 2019/01/08 19:07:30, Peter Somogyi wrote: > I believe we reached consensus to migrate our remaining repositories to > GitBox before the mandatory migration which will happen on 7th of February. > Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty' > repositories that also require the same migration process. > > From users' point of view they could still use git:// > git.apache.org/hbase.git for read only access, only committers need to > change the remote URL to the GitBox one. Jenkins jobs are already using the > GitHub URL for cloning the repository and I created a patch for the > documentation and website changes in HBASE-21685 that we can merge after > the process is competed. > > There's still outstanding work to do before we have good guidelines on > accepting pull requests on GitHub, but the GitBox migration doesn't require > our committers to start working with PRs in a different way. > > If there is no disagreement I'd kindly ask one of the PMC members to reach > out to INFRA to perform the migration. > > Thanks, > Peter > > On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell > wrote: > > > Sounds good to me except squash merge at commit of PR shouldn’t be an > > option it should be required except for good reason (and I don’t know what > > that would be ) > > > > > On Dec 8, 2018, at 3:28 PM, Stack wrote: > > > > > >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote: > > >> > > >> The move to gitbox doesn't require us to only accept github PRs. Given > > >> the current rate of contributions via patches on JIRA vs GitHub PRs, I > > >> wouldn't want to push for that now. > > >> > > >> The change does make it easier for us to start encouraging PR > > >> submissions, because committers will be able to directly merge from > > >> the GitHub UI. > > >> > > >> I'd recommend we try to keep this as a small incremental change. That > > >> would mean: > > >> > > >> * committers ensure there's an associated JIRA for release note and > > >> precommit checks (that can be just by pinging the contributor to go > > >> make one) > > >> * backports are still handled by the committer if they're simple and > > >> the contributor if there's a problem. I think saying "open a new PR to > > >> backport to branch FOO" is perfectly reasonable since it's analogous > > >> to when we ask contributors to attach a branch specific patch. > > >> * committers ensure the pushed commit has a message that follows our > > >> current practice (which would mean looking out for the "helpful" > > >> subject wrapping) > > >> * Squash merge is an option when the committer goes to accept the PR. > > >> the contributor is free to either push additional commits or squash on > > >> their branch when working through reviews, I don't think we need to > > >> weigh in on how contributors choose which of those works best for > > >> them. > > >> > > >> That way we can also incrementally improve how well we handle PR > > >> submissions by better documenting expectations and building up > > >> additional tooling (e.g. having our precommit feedback go directly to > > >> the PR instead of being tied to a JIRA) > > >> > > > > > > This seems reasonable to me. Andrew's strawman would be too radical a > > > change. > > > Thanks, > > > S > > > > > > > > >>> On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: > > >>> > > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey wrote: > > > > 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 > > sooner > > rather than later. > > > > I think we should move to gitbox ASAP rather than wait for the crunch. > > >> If > > we hit a rough spot we're more likely to get some help when things > > >> aren't > > busy. Maybe we wait until our open RCs close so that folks that need > > >> to tag > > those releases don't need to update their workflow first? > > > > Presuming everyone still agrees that we get value out of JIRA, I think > > >> we > > need update our committer guidelines to expressly remind folks to > > >> check on > > things like commit messages before merging PRs, as well as to ensure > > >> folks > > use the "squash and merge" option to keep the git history less > > >> complicated. > > Probably a good time to add text about the importance of backporting, > > >> since > > there isn't a github UI for doing that. > > > > >>> > > >>> > > >>> Sounds good. > > >>> > > >>> Use this thread to list what needs documentation? (Agree with the "Need > >
Re: [DISCUSS] move to gitbox
Created HBASE-21701 'Accept pull requests from contributors' and added to a comment what was collected until now. Feel free to add more there! On Wed, Jan 9, 2019 at 11:22 AM Tamas Penzes wrote: > +1 for rebase and merge. > > It is the most understandable merge strategy. Others can cause huge > confusion when checking the history. > > On Wed, Jan 9, 2019, 00:19 Ankit Singhal > > Just sharing what other communities are thinking on some of the merging > > strategies provided by github for pull requests:- > > > > > https://lists.apache.org/thread.html/c41aef9a33548de8e543d01611e71316c1cd0b0d0a75fb583d609ae1@%3Cdev.calcite.apache.org%3E > > > > "default merge pull request" option:- > > Affects the linear history of the commits , it will be hard to follow > which > > is commit recently. > > https://help.github.com/articles/about-pull-request-merges/ > > > > "Squash merge" option:- > > Calcite community is considering of disabling the feature from Github and > > delegating it to the author to squash all their commit before it can be > > merged by the committer so that original author of the PR can be > preserved > > in the squashed commit. > > > > "rebase and merge" option:- > > This is how most of the apache projects currently doing through git > client, > > It will preserves the author and linear history of the commit.(also > tested > > by calcite community and said on below blog) > > https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/ > > > > So , we may should consider disabling the ones which doesn't suit us to > > avoid committers using them accidentally. > > > > Regards, > > Ankit Singhal > > > > > > On Tue, Jan 8, 2019 at 11:07 AM Peter Somogyi > wrote: > > > > > I believe we reached consensus to migrate our remaining repositories to > > > GitBox before the mandatory migration which will happen on 7th of > > February. > > > Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty' > > > repositories that also require the same migration process. > > > > > > From users' point of view they could still use git:// > > > git.apache.org/hbase.git for read only access, only committers need to > > > change the remote URL to the GitBox one. Jenkins jobs are already using > > the > > > GitHub URL for cloning the repository and I created a patch for the > > > documentation and website changes in HBASE-21685 that we can merge > after > > > the process is competed. > > > > > > There's still outstanding work to do before we have good guidelines on > > > accepting pull requests on GitHub, but the GitBox migration doesn't > > require > > > our committers to start working with PRs in a different way. > > > > > > If there is no disagreement I'd kindly ask one of the PMC members to > > reach > > > out to INFRA to perform the migration. > > > > > > Thanks, > > > Peter > > > > > > On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell < > andrew.purt...@gmail.com > > > > > > wrote: > > > > > > > Sounds good to me except squash merge at commit of PR shouldn’t be an > > > > option it should be required except for good reason (and I don’t know > > > what > > > > that would be ) > > > > > > > > > On Dec 8, 2018, at 3:28 PM, Stack wrote: > > > > > > > > > >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey > > wrote: > > > > >> > > > > >> The move to gitbox doesn't require us to only accept github PRs. > > Given > > > > >> the current rate of contributions via patches on JIRA vs GitHub > > PRs, I > > > > >> wouldn't want to push for that now. > > > > >> > > > > >> The change does make it easier for us to start encouraging PR > > > > >> submissions, because committers will be able to directly merge > from > > > > >> the GitHub UI. > > > > >> > > > > >> I'd recommend we try to keep this as a small incremental change. > > That > > > > >> would mean: > > > > >> > > > > >> * committers ensure there's an associated JIRA for release note > and > > > > >> precommit checks (that can be just by pinging the contributor to > go > > > > >> make one) > > > > >> * backports are still handled by the committer if they're simple > and > > > > >> the contributor if there's a problem. I think saying "open a new > PR > > to > > > > >> backport to branch FOO" is perfectly reasonable since it's > analogous > > > > >> to when we ask contributors to attach a branch specific patch. > > > > >> * committers ensure the pushed commit has a message that follows > our > > > > >> current practice (which would mean looking out for the "helpful" > > > > >> subject wrapping) > > > > >> * Squash merge is an option when the committer goes to accept the > > PR. > > > > >> the contributor is free to either push additional commits or > squash > > on > > > > >> their branch when working through reviews, I don't think we need > to > > > > >> weigh in on how contributors choose which of those works best for > > > > >> them. > > > > >> > > > > >> That way we can also incrementally improve how well we handle PR > > > > >> submissions by better documenting
[jira] [Created] (HBASE-21701) Accept pull requests from contributors
Peter Somogyi created HBASE-21701: - Summary: Accept pull requests from contributors Key: HBASE-21701 URL: https://issues.apache.org/jira/browse/HBASE-21701 Project: HBase Issue Type: Task Components: community, documentation Reporter: Peter Somogyi With the move to GitBox we can easily accept pull requests. On the thread ([https://s.apache.org/08Fh]) about moving to GitBox good suggestions came up. This need to be standardized and documented before HBase is open for PRs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-21652) Refactor ThriftServer making thrift2 server inherited from thrift1 server
[ https://issues.apache.org/jira/browse/HBASE-21652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Yang reopened HBASE-21652: > Refactor ThriftServer making thrift2 server inherited from thrift1 server > - > > Key: HBASE-21652 > URL: https://issues.apache.org/jira/browse/HBASE-21652 > Project: HBase > Issue Type: Sub-task >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-21652.addendum.patch, HBASE-21652.branch-2.patch, > HBASE-21652.patch, HBASE-21652.v2.patch, HBASE-21652.v3.patch, > HBASE-21652.v4.patch, HBASE-21652.v5.patch, HBASE-21652.v6.patch, > HBASE-21652.v7.patch > > > Except the different protocol, thrift2 Server should have no much difference > from thrift1 Server. So refactoring the thrift server, making thrift2 server > inherit from thrift1 server. Getting rid of many duplicated code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21700) Rewrite RSGroupInfoManagerImpl to use AsyncClusterConnection
Duo Zhang created HBASE-21700: - Summary: Rewrite RSGroupInfoManagerImpl to use AsyncClusterConnection Key: HBASE-21700 URL: https://issues.apache.org/jira/browse/HBASE-21700 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang Or maybe even do not use ClusterConnection related stuffs. The code is super complicated and seems over kill, as we only need to create the system table if it does not exist... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] move to gitbox
+1 for rebase and merge. It is the most understandable merge strategy. Others can cause huge confusion when checking the history. On Wed, Jan 9, 2019, 00:19 Ankit Singhal Just sharing what other communities are thinking on some of the merging > strategies provided by github for pull requests:- > > https://lists.apache.org/thread.html/c41aef9a33548de8e543d01611e71316c1cd0b0d0a75fb583d609ae1@%3Cdev.calcite.apache.org%3E > > "default merge pull request" option:- > Affects the linear history of the commits , it will be hard to follow which > is commit recently. > https://help.github.com/articles/about-pull-request-merges/ > > "Squash merge" option:- > Calcite community is considering of disabling the feature from Github and > delegating it to the author to squash all their commit before it can be > merged by the committer so that original author of the PR can be preserved > in the squashed commit. > > "rebase and merge" option:- > This is how most of the apache projects currently doing through git client, > It will preserves the author and linear history of the commit.(also tested > by calcite community and said on below blog) > https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/ > > So , we may should consider disabling the ones which doesn't suit us to > avoid committers using them accidentally. > > Regards, > Ankit Singhal > > > On Tue, Jan 8, 2019 at 11:07 AM Peter Somogyi wrote: > > > I believe we reached consensus to migrate our remaining repositories to > > GitBox before the mandatory migration which will happen on 7th of > February. > > Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty' > > repositories that also require the same migration process. > > > > From users' point of view they could still use git:// > > git.apache.org/hbase.git for read only access, only committers need to > > change the remote URL to the GitBox one. Jenkins jobs are already using > the > > GitHub URL for cloning the repository and I created a patch for the > > documentation and website changes in HBASE-21685 that we can merge after > > the process is competed. > > > > There's still outstanding work to do before we have good guidelines on > > accepting pull requests on GitHub, but the GitBox migration doesn't > require > > our committers to start working with PRs in a different way. > > > > If there is no disagreement I'd kindly ask one of the PMC members to > reach > > out to INFRA to perform the migration. > > > > Thanks, > > Peter > > > > On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell > > > wrote: > > > > > Sounds good to me except squash merge at commit of PR shouldn’t be an > > > option it should be required except for good reason (and I don’t know > > what > > > that would be ) > > > > > > > On Dec 8, 2018, at 3:28 PM, Stack wrote: > > > > > > > >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey > wrote: > > > >> > > > >> The move to gitbox doesn't require us to only accept github PRs. > Given > > > >> the current rate of contributions via patches on JIRA vs GitHub > PRs, I > > > >> wouldn't want to push for that now. > > > >> > > > >> The change does make it easier for us to start encouraging PR > > > >> submissions, because committers will be able to directly merge from > > > >> the GitHub UI. > > > >> > > > >> I'd recommend we try to keep this as a small incremental change. > That > > > >> would mean: > > > >> > > > >> * committers ensure there's an associated JIRA for release note and > > > >> precommit checks (that can be just by pinging the contributor to go > > > >> make one) > > > >> * backports are still handled by the committer if they're simple and > > > >> the contributor if there's a problem. I think saying "open a new PR > to > > > >> backport to branch FOO" is perfectly reasonable since it's analogous > > > >> to when we ask contributors to attach a branch specific patch. > > > >> * committers ensure the pushed commit has a message that follows our > > > >> current practice (which would mean looking out for the "helpful" > > > >> subject wrapping) > > > >> * Squash merge is an option when the committer goes to accept the > PR. > > > >> the contributor is free to either push additional commits or squash > on > > > >> their branch when working through reviews, I don't think we need to > > > >> weigh in on how contributors choose which of those works best for > > > >> them. > > > >> > > > >> That way we can also incrementally improve how well we handle PR > > > >> submissions by better documenting expectations and building up > > > >> additional tooling (e.g. having our precommit feedback go directly > to > > > >> the PR instead of being tied to a JIRA) > > > >> > > > > > > > > This seems reasonable to me. Andrew's strawman would be too radical a > > > > change. > > > > Thanks, > > > > S > > > > > > > > > > > >>> On Fri, Dec 7, 2018 at 12:09 PM Stack wrote: > > > >>> > > > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey > > wrote: > > > > > > Hi folks! > > >
