Re: Revisit the proposal to use github PR
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 , 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.
On Thu, Dec 13, 2018 at 9:20 AM Aleksey Yeschenko <aleksey@xxxxxxxxxxxxx>
> 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.
> > On 13 Dec 2018, at 08:15, Sylvain Lebresne <lebresne@xxxxxxxxx> 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
> > 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.joshi@xxxxxxxxx.INVALID
> > <email@example.com> wrote:
> >> I've been already using github PRs for some time now. Once you specify
> >> ticket number, the comments and discussion are persisted in Apache Jira
> >> 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
> >> 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
> >> aweful.
> >> Dinesh
> >> On Thursday, December 13, 2018, 1:10:12 AM GMT+5:30, Benedict Elliott
> >> Smith <benedict@xxxxxxxxxx> 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
> >> for a branch in the comments.
> >>> On 12 Dec 2018, at 19:20, jay.zhuang@xxxxxxxxx.INVALID wrote:
> >>> It was discussed 1 year's ago:
> >> https://www.mail-archive.com/dev@xxxxxxxxxxxxxxxxxxxx/msg11810.html
> >>> As all Apache projects are moving to gitbox:
> >> https://reference.apache.org/committer/github, should we revisit that
> >> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx