When I open a pull request to Beam, it is on by default. I have just run an experiment to see if it is remembering the last option I checked and it is not. Even after I disable it for one pull request, the next one has it checked again. So it may be a repository-level setting that you can set up.
Kenn On Wed, May 16, 2018 at 11:19 AM Chesnay Schepler <ches...@apache.org> wrote: > This however has to be enabled by the contributor, separately for each PR. > We'll see how often we get the opportunity to use it. > > On 16.05.2018 17:43, Kenneth Knowles wrote: > > Actually, GitHub has a feature so you do not require picture-perfect > > commits: > > > https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/ > > > > If the owner of the PR checks the box, it will give committers write > access > > to their branch (on their fork). A nice bonus is you can make the changes > > and then continue the review, too. > > > > Kenn > > > > On Wed, May 16, 2018 at 8:31 AM Stefan Richter < > s.rich...@data-artisans.com> > > wrote: > > > >> +1 > >> > >>> Am 16.05.2018 um 12:40 schrieb Chesnay Schepler <ches...@apache.org>: > >>> > >>> Hello, > >>> > >>> during the discussion about how to better manage pull requests [1] the > >> topic of GitBox integration came up again. > >>> This seems like a good opportunity to restart this discussion that we > >> had about a year ago [2]. > >>> * What is GitBox > >>> > >>> Essentially, GitBox allow us to use GitHub features. > >>> We can decide for ourselves which features we want enabled. > >>> > >>> We could merge PRs directly on GitHub at the button of a click. > >>> That said the merge functionality is fairly limited and would > >>> require picture-perfect commits in the pull requests. > >>> Commits can be squashed, but you cannot amend commits in any way, be > >>> it fixing typos or changing the commit message. Realistically this > >>> limits how much we can use this feature, and it may lead to a > >>> decline in the quality of commit messages. > >>> > >>> Labels can be useful for the management of PRs as (ready for review, > >>> delayed for next release, waiting for changes). This is really what > >>> I'm personally most interested in. > >>> > >>> We've been using GitBox for flink-shaded for a while now and i > >>> didn't run into any issue. AFAIK GitBox is also the default for new > >>> projects. > >>> > >>> * What this means for committers: > >>> > >>> The apache git remote URL will change, which will require all > >>> committers to update their git setup. > >>> This also implies that we may have to update the website build > scripts. > >>> The new URL would (probably) be > >>> /https://gitbox.apache.org/repos/asf/flink.git/. > >>> > >>> To make use of GitHub features you have to link your GitHub and > >>> Apache accounts. [3] > >>> This also requires setting up two-factor authentication on GitHub. > >>> > >>> Update the scm entry in the parent pom.xml. > >>> > >>> * What this means for contributors: > >>> > >>> Nothing should change for contributors. Small changes (like typos) > >>> may be merged more quickly, if the commit message is appropriate, as > >>> it could be done directly through GitHub. > >>> > >>> [1] > >> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Closing-automatically-inactive-pull-requests-tt22248.html > >>> [2] > >> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-GitBox-td18027.html > >>> [3] https://gitbox.apache.org/setup/ > >> > >
