Since there seems to be agreement, I opened a ticket (CASSANDRA-17837) and
a pull request (https://github.com/apache/cassandra/pull/1799) in so that
the final text can be hashed out and accepted.
I also used the proposed pull request in the text of the pull so that it
can be seen in all its glory
Link to next episode:
Ep7 - Ekaterina Dimitrova (Apache Cassandra committer)
https://drive.google.com/file/d/1xgwHOdufJAEwjlAluJZP2XwfbGpFWEwv/view?usp=sharing
(You may have to download it to listen)
It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, August 22
The test build of Cassandra 4.0.6 is available.
>
> sha1:
>
The sha is eb2375718483f4c360810127ae457f2a26ccce67
The test build of Cassandra 4.0.6 is available.
sha1:
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.6-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1275/org/apache/cassandra/cassandra-all/4.0.6/
The Source an
> I have never seen this
> kind of git merging strategy elsewhere, I am not sure if I am not
> experienced enough or we are truly unique the way we do things.
I am very fond of this project and this community. THAT SAID ;) you could
replace "kind of git merging strategy" with a lot of different th
Interesting, thanks for explicitly writing that down. I humbly think
the CI and the convenience of the GitHub workflow is ultimately
secondary when it comes to the code-base as such. Indeed, nice to
have, but if it turns out to be uncomfortable in other ways, I guess
we just have to live with what
The benefits being extolled involve people setting up GitHub bots to integrate
with PRs to run CI etc, which will require some non-trivial investment by
somebody to put together
The alternative merge strategy being discussed is not to merge, but to instead
cherry-pick or rebase. This means we c
No chicken-egg to me. All it takes is ctrl+c & ctrl+v on your merging
commits. How would new merging strategy actually look like? I am all
ears. This seems to be quite nice as is if we stick to be more verbose
what we did.
On Thu, 18 Aug 2022 at 20:27, Benedict wrote:
>
> Was it?
>
> I mean, we’v
Was it?
I mean, we’ve all (or most) I think worked on projects with those things, so we
all know what the benefits are?
It’s fair to point out that we don’t have it even running for any branch yet.
However there’s perhaps a chicken-and-egg situation, where I’m unsure the
investment to develop
>
> That debatable benefit aside, not doing merge commits would also open up
> options for us to use PR's for merges and integrate running CI, and
> blocking on clean CI, pre-merge. Which has some other pretty big benefits.
> :)
>
The past agreement IIRC was to start doing those things on trunk-o
--
Best Regards,
Ajai Joy
re: history on merges, there's probably some incantation in idea I haven't yet
uncovered to be able to stay in one environment instead of having to jump out
to a terminal to dig into something. I'm a bit of a stickler when it comes to
optimizing workflow; this may just be a Me Thing.
> Having d
I will gladly apply commit messages to merge commits as well from now
on (or when we formally vote on that, if you prefer).
On Thu, 18 Aug 2022 at 18:21, Mick Semb Wever wrote:
>
>
>> There's `git merge --log` which provides a short-form log in the merge
>> commit.
>
>
>
> Let's do it!
>
> Can a
> There's `git merge --log` which provides a short-form log in the merge
> commit.
>
Let's do it!
Can anyone see the problem in having some of our new merge commits with
this additional info, in the hope it will just catch on and become the norm
(precedence > policy) ?
On 18/08/2022 18.46, Mick Semb Wever wrote:
Until IDEs auto cross-reference JIRA,
I'm going to lightly touch the lid of Pandora's Box here and walk
away slowly. It drives me *nuts* when I'm git blaming a file to
understand the context of why a change was made (to make sure I
Until IDEs auto cross-reference JIRA,
>
> I'm going to lightly touch the lid of Pandora's Box here and walk away
> slowly. It drives me *nuts* when I'm git blaming a file to understand the
> context of why a change was made (to make sure I continue to respect it!)
> and I see "merge 3.11 into trunk
Let’s change our merge strategy!
I really want us to. Perhaps I should start a formal discussion about it, and
afterwards we can see where the votes land.
> On 18 Aug 2022, at 15:37, Josh McKenzie wrote:
>
>
>>
>> Until IDEs auto cross-reference JIRA,
> I'm going to lightly touch the lid of
Thinking about this a little bit more, I am not sure what would change
in practice if we introduced such a policy (of adding messages to
merge commits). We are not automatically enforcing the current format
of commit messages so why is it a problem we would not enforce the
format of commit messages
Actually, yes. We can even all agree on that, the thing is who is
going to actually enforce it when it is solely upon an actual
committer to stick with the policy. What I tend to see in the other
projects is that they have even automatic checks on commit message
format but given the fact how we are
> this should be pretty easy to incorporate into the workflow?
The hard part isn't incorporating this into one's workflow, the hard part is
getting all of us to agree that this is something we should all do and
formalize it as our project process. :)
On Thu, Aug 18, 2022, at 10:41 AM, Stefan Mik
A few thoughts:
1. If we gate the classification behind each test failure being root-caused,
we consistently need people who are dedicating their time to doing that or we
end up with a backlog of unclassified CI failures (like we have now and have
always had historically).
2. Newcomers to the
Adding commit messages into merge commits for increased understanding
of the codebase when you are git-blaming is the absolute minimum we
can do to help you with (not only) your frustration. merging with -s
ours opens up an editor where you do have a possibility to tweak the
message as you wish so
> I think a simple metric for "is something flaky" is "does it only fail once
> in the butler history (of 15 or so builds)".
Does that make it considered flaky? What if the one failure is a
timeout? I think each failing case has to have the failures
investigated in order to know.
Kind Regards,
> Until IDEs auto cross-reference JIRA,
I'm going to lightly touch the lid of Pandora's Box here and walk away slowly.
It drives me *nuts* when I'm git blaming a file to understand the context of
why a change was made (to make sure I continue to respect it!) and I see "merge
3.11 into trunk" or
So move to beta when:
1. all non-flaky test *failures* (NOT tickets, see below) are resolved
2. We get a green ci-cassandra run
Move to rc when:
1. Three consecutive green runs in ci-cassandra
Release when:
1. All rc tickets are closed
2. Some time-based gate maybe?
3. Three more consecutive
I could not quickly find which test does specifically this, but you could
induce schema disagreements with dtests in two ways, from the top of my head:
1. dtests with verb filters; disabling schema mutations
2. by executing schema statements with NODE_LOCAL / executeInternal on the node
rather t
> My understanding is that ICLA is not required for every single
> contributor. I don’t think we ask anybody to sign it unless they’re a
> committer.
>
That's not accurate. The ASF requires that any significant contribution
requires a i(CLA), committer or not.
> I would strongly encourage tha
I’m all for having a consistent template but the legal disclaimer is something
I personally dislike and will discourage contributions. My understanding is
that ICLA is not required for every single contributor. I don’t think we ask
anybody to sign it unless they’re a committer. Under the Apache
On Thu, 18 Aug 2022 at 08:10, Benedict wrote:
> Yes, I strongly endorse long form commit messages, though I’m often remiss
> about them myself. Until IDEs auto cross-reference JIRA, and we start
> sanitising our JIRA summaries, a commit record is going to be a better
> description of what has bee
On Thu, 18 Aug 2022 at 08:10, Benedict wrote:
> > By submitting this pull request, I acknowledge that I am making a
> contribution to the Apache Software Foundation under the terms and
> conditions of the [Contributor's Agreement](
> https://www.apache.org/licenses/contributor-agreements.html).
>
30 matches
Mail list logo
