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
> 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
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
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
> 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
> 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).
>
> 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).
Do we expect every contributor who makes any con
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 been done and why.
I think Jon is another proponent, wh
Yes, it's me. Guilty as charged. 😁
I appreciate the acknowledgement. Cheers!
On Thu, 18 Aug 2022 at 03:00, Amit Aggarwal
wrote:
> Hi Erick,
>
> If you are the same Erick, Thank you for answering lots of questions
> related to Cassandra on stack overflow.
>
>
> Thanks
> Amit Aggarwal
>
> On 16-A
Hi Erick,
If you are the same Erick, Thank you for answering lots of questions related to
Cassandra on stack overflow.
Thanks
Amit Aggarwal
> On 16-Aug-2022, at 2:28 PM, Erick Ramirez wrote:
>
> I forgot to mention that whatever gets decided, I think it should be
> implemented across all
> something more descriptive like "Describe what the pull request fixes, why it
> is needed, and what branch(s) you expect it to be applied to."
I recall us having a conversation a long while ago about our commit messages
and whether they're optimal in their current format (defer all context to J
I forgot to mention that whatever gets decided, I think it should be
implemented across all GitHub repos of the project. See here for the
complete list -- https://projects.apache.org/committee.html?cassandra.
Cheers!
I am all for simplification. How about
- start of text
Issue resolved: CASSANDRA-
- [ ] Jira ticket contains a description of: what is fixed, why it is
needed, and what branches to apply it to.
- [ ] Commits have been squashed to remove intermediate development
commit message
Sorry. I hit "send" before pasting the link:
[1] https://cassandra.apache.org/_/development/patches.html
+1 this is a great idea. But personally, I'm not too fussed about the level
of detail that is in the template -- what is important is that contributors
are reminded that there needs to be a ticket associated with contributions.
Without being too prescriptive, aspiring contributors should really
fam
> If there is consensus that the PR template is a good idea, I'll create a
> branch and we can wrangle the words.
>
> I think the pull request generally is against a specific branch but having
> the branch listed in the template is not a bad idea. I do want to avoid
> having too many questions. W
If there is consensus that the PR template is a good idea, I'll create a
branch and we can wrangle the words.
I think the pull request generally is against a specific branch but having
the branch listed in the template is not a bad idea. I do want to avoid
having too many questions. We could cha
I like auto linking, definitely a handy feature.
I am not sure about the content of the pull request description. I
would include what that PR is actually for / why it is necessary to
merge it and into what branches a contributor expects that PR to be
merged in. However, this might be omitted if a
Github provides the ability to add a pull request template [1]. I think
that such a template could assist in making the pull requests better.
Something like the text below, along with verifying that CASSANDRA-### will
link to Jira [2], should provide the information needed and remind
submitters of
35 matches
Mail list logo
