+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
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
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
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
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
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
>
+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:-
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
22 matches
Mail list logo
