codehaus


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 [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 <aleksey@xxxxxxxxxxxxx>
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 <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
> 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.joshi@xxxxxxxxx.INVALID
> > <dinesh.joshi@xxxxxxxxx.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 <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
> hunting
> >> 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
> 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-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
>
>