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
I’m honestly not sure. The code has changed since I last worked on it, which
was years ago. I suspect the profile mode has entirely supplanted the prior
modes, and that these older modes supported the HexStrings generator.
Perhaps somebody else can help answer this question.
> On 13 Dec
Ah ok thanks. This brings up another question: how did the HexStrings generator
code path even get called?
When I saw these results, I was using the following test table:
CREATE TABLE testtable (
partition_key text,
clustering_column text,
value text,
PRIMARY KEY
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
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
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
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
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
