Re: Arrow sync call November 25 at 12:00 US/Eastern, 17:00 UTC

2020-11-25 Thread Jorge Cardoso Leitão
Hi, There was no topic to discuss, so we called it a day. Have a good thanksgiving folks in the US and elsewhere :) Best, Jorge On Wed, Nov 25, 2020 at 5:44 PM Neal Richardson wrote: > Hi all, > Reminder that our biweekly call is coming up at > https://meet.google.com/vtm-teks-phx. All are

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Jacques Nadeau
> > I don’t have a problem with releasing out of branches. I think I (or > someone) proposed this in the past and there was not consensus but it seems > like a good time to revisit the issue. > Thanks for the recap. I just couldn't remember where people were at on this. I'm a big +1 for

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Wes McKinney
I don’t have a problem with releasing out of branches. I think I (or someone) proposed this in the past and there was not consensus but it seems like a good time to revisit the issue. On Wed, Nov 25, 2020 at 7:41 PM Jacques Nadeau wrote: > I'm catching up here. A couple questions. > >- I

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Jacques Nadeau
I'm catching up here. A couple questions. - I don't think we should require the inclusion of the release commits in the main branch. Having leafs created right before release seems to simplify this and resolve any issues around force PRs, no? Or maybe I'm misunderstanding something?

Re: ursa-labs/crossbow on travis-ci.com is disabled

2020-11-25 Thread Jeroen Ooms
On Wed, Nov 25, 2020 at 10:54 PM Sutou Kouhei wrote: > > Hi, > > In > "Re: ursa-labs/crossbow on travis-ci.com is disabled" on Tue, 24 Nov 2020 > 13:36:54 +0100, > Krisztián Szűcs wrote: > > > Confirmed, we already have a negative credit balance due to travis' > > new billing strategy. > >

Re: ursa-labs/crossbow on travis-ci.com is disabled

2020-11-25 Thread Sutou Kouhei
Hi, In "Re: ursa-labs/crossbow on travis-ci.com is disabled" on Tue, 24 Nov 2020 13:36:54 +0100, Krisztián Szűcs wrote: > Confirmed, we already have a negative credit balance due to travis' > new billing strategy. > The macos wheels quickly consume the credit based free tier, so travis >

Re: [Discuss] Bearer Token refresh design with retry mechanism

2020-11-25 Thread Keerat Singh
Thank you David for the prompt response, I will take a look and respond to them. Regards, Keerat On Wed, Nov 25, 2020 at 11:51 AM David Li wrote: > Hi Kerrat, > > Please see my comments in the doc - I think I commented while this email > went out. I would prefer to just retry on

Re: [Discuss] Bearer Token refresh design with retry mechanism

2020-11-25 Thread David Li
Hi Kerrat, Please see my comments in the doc - I think I commented while this email went out. I would prefer to just retry on UNAUTHENTICATED. Also, with gRPC and especially with streaming calls, you may not get an error status right away, as you've found - so there's additional work needed to

Re: [Discuss] Bearer Token refresh design with retry mechanism

2020-11-25 Thread David Li
Having retries seems reasonable to me, I've added some comments on the linked doc. Best, David On Wed, Nov 25, 2020, at 14:18, Wes McKinney wrote: > In principle adding a new error code for this seems reasonable to me. > What do you think about calling it something more generic like >

Re: [Discuss] Bearer Token refresh design with retry mechanism

2020-11-25 Thread Keerat Singh
Hey Wes, Renaming it to be more generic like AUTH_EXPIRED sounds good to me, updated the design doc. RE: The implementation, while working on the Java POC for this: - Adding it to the FlightStatusCode

Re: [Discuss] Bearer Token refresh design with retry mechanism

2020-11-25 Thread Wes McKinney
In principle adding a new error code for this seems reasonable to me. What do you think about calling it something more generic like "AUTH_EXPIRED"? I haven't looked at the details of the implementation -- David Li or others may be able to provide better comments? On Fri, Nov 20, 2020 at 6:23 PM

Arrow sync call November 25 at 12:00 US/Eastern, 17:00 UTC

2020-11-25 Thread Neal Richardson
Hi all, Reminder that our biweekly call is coming up at https://meet.google.com/vtm-teks-phx. All are welcome to join. Notes will be sent out to the mailing list afterward (though not by me since I won't be there--please someone else do the notetaking today). Neal

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Wes McKinney
Note that at any time you can change your GitHub settings to disallow your branches from being edited by maintainers. On Wed, Nov 25, 2020 at 7:51 AM Wes McKinney wrote: > > > The first two sound logical, but why couldn't those version bumps be a > merge commit into master? > > We've made the

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Wes McKinney
> The first two sound logical, but why couldn't those version bumps be a merge commit into master? We've made the commitment to maintaining a linear commit history in this project. Auto-rebasing the PRs at this point is best described as "harm reduction". The root cause is GitHub's UI which

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Jörn Horstmann
Is there more documentation why a force push to master is necessary? I read https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Mainsourcereleaseandvote which says - The local release branch has some unpushed commits such as bumping to the next

[NIGHTLY] Arrow Build Report for Job nightly-2020-11-25-0

2020-11-25 Thread Crossbow
Arrow Build Report for Job nightly-2020-11-25-0 All tasks: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-11-25-0 Failed Tasks: - test-conda-python-3.7-spark-branch-3.0: URL:

Re: [Governance] [Proposal] Stop force-pushing to PRs after release?

2020-11-25 Thread Uwe L. Korn
Hello Jorge, I know from the past on the Python/C++ side, we needed to do this for a lot of contributors to enable them to work with their branches/PRs again as they were overwhelmed with the complexity of these rebases. Personally, I wouldn't like to spend much time on whether we should