I'm with Sylvain and Aleksey. Our multi-branch strategy does not work well (if at all) with Github PR-style workflows (and, yes, I and most c* maintainers have played this game). The cassandra-dtests repo is different as we don't really branch there, so might be fine for Github PRs - except for the merge commit noise, and that we prefer squashed patches for commit.
We could perhaps be a bit more explicit about "how to contribute" in the docs [1], wrt branches as well as Github PRs (that we don't do them), but it's mostly not unreasonable. Thus, I'm in favor of the current process. [1] http://cassandra.apache.org/doc/latest/development/patches.html On Thu, Dec 13, 2018 at 9:20 AM Aleksey Yeschenko <alek...@yeschenko.com> wrote: > There are some nice benefits to GH PRs, one of them is that we could > eventually set up CircleCI hooks that would explicitly prevent commits that > don’t pass the tests. > > But handling multiple branches would indeed be annoying. Would have to > either submit 1 PR per branch - which is both tedious and non-atomic - or > do a mixed approach, with a PR for the oldest branch, then a manual merge > upwards. The latter would be kinda meh, especially when commits for > different branches diverge. > > For me personally, the current setup works quite well, and I mostly share > Sylvain’s opinion above, for the same reasons listed. > > — > AY > > > On 13 Dec 2018, at 08:15, Sylvain Lebresne <lebre...@gmail.com> wrote: > > > > Fwiw, I personally find it very useful to have all discussion, review > > comments included, in the same place (namely JIRA, since for better or > > worse, that's what we use for tracking tickets). Typically, that means > > everything gets consistently pushed to the commits@ mailing list, > which I > > find extremely convenient to keep track of things. I also have a theory > > that the inline-comments type of review github PR give you is very > > convenient for nitpicks, shallow or spur-of-the-moment comments, but > > doesn't help that much for deeper reviews, and that it thus to favor the > > former kind of review. > > > > Additionally, and to Benedict's point, I happen to have first hand > > experience with a PR-based process for a multi-branch workflow very > similar > > to the one of this project, and suffice to say that I hate it with a > > passion. > > > > Anyway, very much personal opinion here. > > -- > > Sylvain > > > > > > On Thu, Dec 13, 2018 at 2:13 AM dinesh.jo...@yahoo.com.INVALID > > <dinesh.jo...@yahoo.com.invalid> wrote: > > > >> I've been already using github PRs for some time now. Once you specify > the > >> ticket number, the comments and discussion are persisted in Apache Jira > as > >> work log so it can be audited if desired. However, committers usually > >> squash and commit the changes once the PR is approved. We don't use the > >> merge feature in github. I don't believe github we can merge the commit > >> into multiple branches through the UI. We would need to merge it into > one > >> branch and then manually merge that commit into other branches. The big > >> upside of using github PRs is that it makes collaborating a lot easier. > >> Downside is that it makes it very difficult to follow along the > progress in > >> Apache Jira. The messages that github posts back include huge diffs and > are > >> aweful. > >> Dinesh > >> > >> On Thursday, December 13, 2018, 1:10:12 AM GMT+5:30, Benedict Elliott > >> Smith <bened...@apache.org> wrote: > >> > >> Perhaps somebody could summarise the tradeoffs? I’m a little concerned > >> about how it would work for our multi-branch workflow. Would we open > >> multiple PRs? > >> > >> Could we easily link with external CircleCI? > >> > >> It occurs to me, in JIRA proposal mode, that an extra required field > for a > >> permalink to GitHub for the patch would save a lot of time I spend > hunting > >> for a branch in the comments. > >> > >> > >> > >> > >>> On 12 Dec 2018, at 19:20, jay.zhu...@yahoo.com.INVALID wrote: > >>> > >>> It was discussed 1 year's ago: > >> https://www.mail-archive.com/dev@cassandra.apache.org/msg11810.html > >>> As all Apache projects are moving to gitbox: > >> https://reference.apache.org/committer/github, should we revisit that > and > >> change our review/commit process to use github PR?A good example is > >> Spark:"Changes to Spark source code are proposed, reviewed and committed > >> via Github pull requests" (https://spark.apache.org/contributing.html). > >>> /jay > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
