Re: [DISCUSS] move to gitbox
+1 On 4/6/19 8:22 AM, 张铎(Duo Zhang) wrote: OK, now we have the yetus set up for GitHub PR, and I've tried to use GitHub PR to process several issues. For example HBASE-22174, Sean Busbey approved on the PR, and I used the GitHub PR to commit to master, and then cherry-picked the commit to other branches, and committed them using command line. Worked pretty fine. The only problem is that I accidentally clicked the default merge button and created a merge commit in the commit history... So I'm +1 on only allowing rebase merging, for squash merging, it is not a big deal to let the author squash the commits before merging. And at least, let's disable the default 'Create a Merge Commit' option... Thanks. Sean Busbey 于2019年1月10日周四 上午2:03写道: 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
Re: [DISCUSS] move to gitbox
OK, now we have the yetus set up for GitHub PR, and I've tried to use GitHub PR to process several issues. For example HBASE-22174, Sean Busbey approved on the PR, and I used the GitHub PR to commit to master, and then cherry-picked the commit to other branches, and committed them using command line. Worked pretty fine. The only problem is that I accidentally clicked the default merge button and created a merge commit in the commit history... So I'm +1 on only allowing rebase merging, for squash merging, it is not a big deal to let the author squash the commits before merging. And at least, let's disable the default 'Create a Merge Commit' option... Thanks. Sean Busbey 于2019年1月10日周四 上午2:03写道: > 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
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: [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
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! > > >
Re: [DISCUSS] move to gitbox
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! > > > > 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
Re: [DISCUSS] move to gitbox
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 > >> to > >>> sort all of this out and provide clarity now before a switch over." > from > >>> Andrew). > >>> > >>> What should the commit be like? Should be like now? What about that > ugly > >>> bleed that happens when the first line is too long and gets dumped into > >> the > >>> textbox below ... which then becomes the log IIRC. > >>> > >>> When do we do the squash merge? Is that the committer who does this > after > >>> rounds of review? > >>> > >>> I like Andrew's list. > >>> > >>> On the 'You can't fix a branch-1 issue where the code
Re: [DISCUSS] move to gitbox
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 >> to >>> sort all of this out and provide clarity now before a switch over." from >>> Andrew). >>> >>> What should the commit be like? Should be like now? What about that ugly >>> bleed that happens when the first line is too long and gets dumped into >> the >>> textbox below ... which then becomes the log IIRC. >>> >>> When do we do the squash merge? Is that the committer who does this after >>> rounds of review? >>> >>> I like Andrew's list. >>> >>> On the 'You can't fix a branch-1 issue where the code is different in >>> branch-2 and up by opening a PR against master', this is a prob. at least >>> with our current 'process'. We don't do a JIRA per push because it is >> just >>> a bunch of busy work. Do we have to do this now (any alternatives?) >>> >>> Thanks for starting this up Sean, >>> S >>
Re: [DISCUSS] move to gitbox
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 > to > > sort all of this out and provide clarity now before a switch over." from > > Andrew). > > > > What should the commit be like? Should be like now? What about that ugly > > bleed that happens when the first line is too long and gets dumped into > the > > textbox below ... which then becomes the log IIRC. > > > > When do we do the squash merge? Is that the committer who does this after > > rounds of review? > > > > I like Andrew's list. > > > > On the 'You can't fix a branch-1 issue where the code is different in > > branch-2 and up by opening a PR against master', this is a prob. at least > > with our current 'process'. We don't do a JIRA per push because it is > just > > a bunch of busy work. Do we have to do this now (any alternatives?) > > > > Thanks for starting this up Sean, > > S >
Re: [DISCUSS] move to gitbox
Today if you add a link to a PR on the main repo to a JIRA ticket and put it in patch available status, yetus should properly recognize and use it for testing. The results should go to JIRA like normal. I don't think it's gotten much testing in our setup. (And it wouldn't work on the operator tools or connectors repos because our precommit currently only knows about the main repo.) On Sat, Dec 8, 2018, 01:44 Peter Somogyi How should we verify pull requests in the new workflow? I wouldn't like to > force contributors to create a PR and also attach the same patch file to > Jira to have it tested. In case the plan is to create PR-based precommit > I'd recommend to test run it on hbase-connectors or hbase-operator tools > gitbox repositories. > > > On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey wrote: > > > Yes I definitely agree. I think that'll take some committer practice > > and I'll want to have a decent section in the ref guide to point folks > > to. On the plus side, there's a step committers have to go through to > > link their ASF ID to their GitHub profile before they can start > > merging through the GitHub UI. So if we tell folks about how to do > > that step at the same time as show them how to make sure they're > > squash merging maybe we'll avoid some mistakes. > > On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell > wrote: > > > > > > However you want to best phrase it, squash merging for commit is a > must, > > I > > > think. Depending on the contributor's style there could be 1 or 10 > > commits > > > comprising the PR. Even more than one commit for a change encompassed > by > > a > > > JIRA would make cherry picking between the branches unnecessarily > > onerous. > > > This is really the only thing I'd like to establish as very important. > > > > > > > > > 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) > > > > 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
Re: [DISCUSS] move to gitbox
How should we verify pull requests in the new workflow? I wouldn't like to force contributors to create a PR and also attach the same patch file to Jira to have it tested. In case the plan is to create PR-based precommit I'd recommend to test run it on hbase-connectors or hbase-operator tools gitbox repositories. On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey wrote: > Yes I definitely agree. I think that'll take some committer practice > and I'll want to have a decent section in the ref guide to point folks > to. On the plus side, there's a step committers have to go through to > link their ASF ID to their GitHub profile before they can start > merging through the GitHub UI. So if we tell folks about how to do > that step at the same time as show them how to make sure they're > squash merging maybe we'll avoid some mistakes. > On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell wrote: > > > > However you want to best phrase it, squash merging for commit is a must, > I > > think. Depending on the contributor's style there could be 1 or 10 > commits > > comprising the PR. Even more than one commit for a change encompassed by > a > > JIRA would make cherry picking between the branches unnecessarily > onerous. > > This is really the only thing I'd like to establish as very important. > > > > > > 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) > > > 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 > > > to > > > > sort all of this out and provide clarity now before a switch over." > from > > > > Andrew). > > > > > > > > What should the commit be like? Should be like now? What about that > ugly > > > > bleed that happens when the first line is too long and gets dumped > into > > > the > > > > textbox below ... which then becomes the log IIRC. > > > > > > > > When do we do the squash merge? Is that the committer who does this > after > > > > rounds of review? > > > > > > > > I like
Re: [DISCUSS] move to gitbox
Yes I definitely agree. I think that'll take some committer practice and I'll want to have a decent section in the ref guide to point folks to. On the plus side, there's a step committers have to go through to link their ASF ID to their GitHub profile before they can start merging through the GitHub UI. So if we tell folks about how to do that step at the same time as show them how to make sure they're squash merging maybe we'll avoid some mistakes. On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell wrote: > > However you want to best phrase it, squash merging for commit is a must, I > think. Depending on the contributor's style there could be 1 or 10 commits > comprising the PR. Even more than one commit for a change encompassed by a > JIRA would make cherry picking between the branches unnecessarily onerous. > This is really the only thing I'd like to establish as very important. > > > 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) > > 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 > > to > > > sort all of this out and provide clarity now before a switch over." from > > > Andrew). > > > > > > What should the commit be like? Should be like now? What about that ugly > > > bleed that happens when the first line is too long and gets dumped into > > the > > > textbox below ... which then becomes the log IIRC. > > > > > > When do we do the squash merge? Is that the committer who does this after > > > rounds of review? > > > > > > I like Andrew's list. > > > > > > On the 'You can't fix a branch-1 issue where the code is different in > > > branch-2 and up by opening a PR against master', this is a prob. at least > > > with our current 'process'. We don't do a JIRA per push because it is > > just > > > a bunch of busy work. Do we have to do this now (any alternatives?) > > > > > > Thanks for starting this up Sean, > > > S > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk
Re: [DISCUSS] move to gitbox
However you want to best phrase it, squash merging for commit is a must, I think. Depending on the contributor's style there could be 1 or 10 commits comprising the PR. Even more than one commit for a change encompassed by a JIRA would make cherry picking between the branches unnecessarily onerous. This is really the only thing I'd like to establish as very important. 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) > 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 > to > > sort all of this out and provide clarity now before a switch over." from > > Andrew). > > > > What should the commit be like? Should be like now? What about that ugly > > bleed that happens when the first line is too long and gets dumped into > the > > textbox below ... which then becomes the log IIRC. > > > > When do we do the squash merge? Is that the committer who does this after > > rounds of review? > > > > I like Andrew's list. > > > > On the 'You can't fix a branch-1 issue where the code is different in > > branch-2 and up by opening a PR against master', this is a prob. at least > > with our current 'process'. We don't do a JIRA per push because it is > just > > a bunch of busy work. Do we have to do this now (any alternatives?) > > > > Thanks for starting this up Sean, > > S > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] move to gitbox
Once we can show a consensus position one of the PMC files an INFRA jira and then they coordinate with us (but I don't know specifically what that coordination looks like). On Fri, Dec 7, 2018 at 11:13 AM Misty Linville wrote: > > +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 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. > > > > > > > > > >
Re: [DISCUSS] move to gitbox
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) 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 to > sort all of this out and provide clarity now before a switch over." from > Andrew). > > What should the commit be like? Should be like now? What about that ugly > bleed that happens when the first line is too long and gets dumped into the > textbox below ... which then becomes the log IIRC. > > When do we do the squash merge? Is that the committer who does this after > rounds of review? > > I like Andrew's list. > > On the 'You can't fix a branch-1 issue where the code is different in > branch-2 and up by opening a PR against master', this is a prob. at least > with our current 'process'. We don't do a JIRA per push because it is just > a bunch of busy work. Do we have to do this now (any alternatives?) > > Thanks for starting this up Sean, > S
Re: [DISCUSS] move to gitbox
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 to sort all of this out and provide clarity now before a switch over." from Andrew). What should the commit be like? Should be like now? What about that ugly bleed that happens when the first line is too long and gets dumped into the textbox below ... which then becomes the log IIRC. When do we do the squash merge? Is that the committer who does this after rounds of review? I like Andrew's list. On the 'You can't fix a branch-1 issue where the code is different in branch-2 and up by opening a PR against master', this is a prob. at least with our current 'process'. We don't do a JIRA per push because it is just a bunch of busy work. Do we have to do this now (any alternatives?) Thanks for starting this up Sean, S
Re: [DISCUSS] move to gitbox
In the interest of helping this discussion along, let me change this from an open ended comment to a specific proposal. What if we require a PR for every commit? No cherry picking. This would mean that a change might need three or four, or possibly even five PRs, one for each affected branch. The primary benefit is we fully commit to the GitHub way of managing workflow. We can still do JIRAs but they become independent of commit work. (They kind of are already, if you think about it. A change is reviewed for master and then backported, and the backports may or may not see review themselves, and may or may not be done on a different JIRA, there's no consistency there.) This would have the additional benefit of raising the visibility of changes going into maintenance branches. Rather than have a committer possibly doing cherry picks in the background there would be a nominal PR review cycle for everything. Overall it raises our workload, though. Even if a committer or PMC opts to ignore the additional PRs raised for backports there is still some cognitive work needed to sort through the list of PRs or emails about same and decide what to ignore. Would also require branch maintainers to be responsive to gitbox at-mentions, though. Probably would also require branch maintainers to drive the additional PRs for changes landing in their respective branch(es). What do you think? On Fri, Dec 7, 2018 at 9:23 AM Andrew Purtell wrote: > We also need to discuss and document how to target specific code lines. > You can't fix a branch-1 issue where the code is different in branch-2 and > up by opening a PR against master (assuming this is the default branch). It > seems obvious but is not. Occasionally a fix is relevant for all branches > but needs three or four distinct patches due to differences among the code > lines. In that situation do we require a PR for each distinct change? One > for master, branch-2, and branch-1, and again for branch-1.2, per recent > example? > > Squash merging is a must I think. Otherwise cherry picking changes from > the branch that received the PR changes to other branches is unnecessary > difficult and frankly life is too short. It is difficult enough to > participate in this project already just given the challenges of having > three major code lines and several more releasing branches. > > Or maybe we won't do cherry picks and instead do it by PR for every branch > / commit? > > Need to sort all of this out and provide clarity now before a switch over. > > > On 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. > > > > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] move to gitbox
We also need to discuss and document how to target specific code lines. You can't fix a branch-1 issue where the code is different in branch-2 and up by opening a PR against master (assuming this is the default branch). It seems obvious but is not. Occasionally a fix is relevant for all branches but needs three or four distinct patches due to differences among the code lines. In that situation do we require a PR for each distinct change? One for master, branch-2, and branch-1, and again for branch-1.2, per recent example? Squash merging is a must I think. Otherwise cherry picking changes from the branch that received the PR changes to other branches is unnecessary difficult and frankly life is too short. It is difficult enough to participate in this project already just given the challenges of having three major code lines and several more releasing branches. Or maybe we won't do cherry picks and instead do it by PR for every branch / commit? Need to sort all of this out and provide clarity now before a switch over. > On 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. > > > >
Re: [DISCUSS] move to gitbox
+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 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. > > > > >
[DISCUSS] move to gitbox
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.