+1 Kenneth Knowles <k...@google.com.invalid> schrieb am Mi., 16. Mai 2018, 21:04:
> 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/ > > >> > > > > >
