I don’t particularly like the script approach as it’s not really easy or straightforward in normal cases and when there are things that don’t work it’s actually very difficult to figure out why it’s not possible to commit.
>From an UX perspective there are several burdens: * documenting the script (vs everyone already knows how to use GitHub) * creating token credentials * ensuring correct versions of Python and deps As an example I’ve been fighting with the BK script for a while, with valid credentials and it just fails. Spent a bunch of time to it and still doesn’t work for me. All this, and I don’t see the benefit of that approach. All of the info is already in the PR which is linked int the log message. The squashing of commit is already forced in the GitHub merge. On Wed, Mar 31, 2021 at 8:51 AM Enrico Olivelli <eolive...@gmail.com> wrote: > Hello, > I was talking with Peng Hui about the fact that in BK community we > have this nice script [1] > that performs automatically all of the steps for merging a PR: > - merge with target branch and squashes commits > - keeps the original author of the patch > - create a meaningful commit message > - adds the list of "reviewers" in the commit message > - assigns automatically labels to github issues > - performs cherry-picks to other branches > > As many people in the Pulsar community are part of the BK community, > have you ever evaluated to use that script ? > > The main benefits are: > - it is automatic, so you cannot forget to do something (like setting > the 'assignee' or the 'labels') > - there is an explicit reference to "reviewers" that remains into the > git history > - it is very straightforward, especially for new committers > > Thoughts ? > Enrico > > [1] https://github.com/apache/bookkeeper/blob/master/dev/bk-merge-pr3.py > -- -- Matteo Merli <matteo.me...@gmail.com>
