So, without hopefully getting too dragged into this, I’m honestly not convinced
that GitHub is so phenomenal for review. Though perhaps I just suck at the UX.
- Missed notifications, to both me and seemingly Jira. Jira sometimes fails my
personal email too, but commits@ can be relied upon.
- R
Hi,
Sorry I missed that point. I agree github PRs are not useful for merging.
What I do is force push the feature/bug fix branches (which is fine, github
remembers the old versions in the PR) with everything updated and ready to
merge, and then push those branches from my local repo to the apac
To clarify my position: Github PRs are great for *reviewing* code, and the
commentary is much easier to follow imo. But for *merging* code, esp into
our multi-branch strategy, PRs don't fit well, unless there's some
technique I and perhaps others are unaware of.
On Thu, Dec 13, 2018 at 9:47 AM Ari
Hi,
I'm not clear on what github makes worse. It preserves more history then the
JIRA approach. When people invitably force push their branches you can't tell
from the link to a branch on JIRA. Github preserves the comments and force push
history so you know what version of the code each commen
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
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
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 extreme
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 merg
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
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:"Ch
10 matches
Mail list logo
