Re: Should Skara tooling invalidate approvals when new commits are pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]

2020-01-30 Thread Kevin Rushforth
Hearing no objections, we will enable this for pull requests on the jfx repo starting Tuesday, Feb 4. -- Kevin On 1/8/2020 11:34 AM, Kevin Rushforth wrote: Does anyone strongly feel otherwise? If not, then I'll request the Skara team to enable this feature. -- Kevin On 1/8/2020 11:26 AM,

Re: Should Skara tooling invalidate approvals when new commits are pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]

2020-01-08 Thread Nir Lisker
Looks like an all-or-nothing situation - either any commit requires re-approval or no commit requires re-approval. In this case, I would say that all commits should require re-approval since it's the safer approach. Having the issue stay in approved state after a significant change is much worse

Should Skara tooling invalidate approvals when new commits are pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]

2019-12-31 Thread Kevin Rushforth
Since this isn't directly related to the PR in question, I'm starting a new thread. On 12/20/2019 7:22 PM, Philip Race wrote: On 12/20/19, 7:04 PM, Scott Palmer wrote: I'm not sure if I'me supposed to try to integrate now that I've made that 10 ->  0 change, or if the new change resets the