Re: [Proposal] add pull request template
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). > > Do we expect every contributor who makes any contribution to agree to this? > If we don’t, does it imply anything weird to start stipulating this for PRs > only? Might be worth running past legal, as we don’t expect ICLAs to be > signed for many contributions today, nor any specific assignment besides the > notice at the top of any files in the contribution. > > I’m also not convinced we should be doing much more than letting the user > know they should have read and followed the style guide and contribution > guide, and that before being merged a commit should include documentation > and test changes - but these aren’t probably blockers for an initial > review, and might discourage contributions by making the initial hurdles > appear higher. > It is accurate Benedict. There's past conversations at the foundation level (+legal) about whether this agreement needed to be made explicitly (at the time integration with github was being accepted). The verdict was that it does not need to be explicit when contributing to existing files, because those files are already copyright to the ASF and the contributor is not requesting any change to that. When a contribution adds new files we move towards requiring them to sign a (i)CLA. But even, for simple contributions, this can be tackled implicitly, if fixing any rat errors is on them. If the contributor puts the license header onto the new files, the license includes reference to the copyright owner (being the ASF). I see no harm in providing this information. With a preference as it is just as information (not a checkbox). It's a soft opinion, but I suspect the majority of PRs will be from folk that know all this already and the checkboxes will be ignored.
Re: [Proposal] add pull request template
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 been done and why. > > I think Jon is another proponent, who is more consistent about practicing > what he preaches. It would be great to formalise this as an expectation, as > if we’re honest the cost is *not* high to write a paragraph or two > distilling the work that was done. > I strongly endorse long form commit messages as well. I read the history around anything I'm patching, and am very happy when I come across well written commits (and don't need to jump to the jira ticket).
Re: [Proposal] add pull request template
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 license even emails to the dev or user list, jira comments, slack comments are considered “contributions”. We don’t have disclaimers or acknowledgment each time a contributor emails the dev list. I would strongly encourage that we point new contributors to the getting started page which should cover these details. They need to go through it once and not with each and every PR. Alternatively we could have a GitHub bot that identifies a new contributor and asks them to accept CoC, License agreement, etc for their first PR only. > > On Aug 18, 2022, at 1:01 AM, Mick Semb Wever wrote: > > > > >> 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). >> >> Do we expect every contributor who makes any contribution to agree to this? >> If we don’t, does it imply anything weird to start stipulating this for PRs >> only? Might be worth running past legal, as we don’t expect ICLAs to be >> signed for many contributions today, nor any specific assignment besides the >> notice at the top of any files in the contribution. >> I’m also not convinced we should be doing much more than letting the user >> know they should have read and followed the style guide and contribution >> guide, and that before being merged a commit should include documentation >> and test changes - but these aren’t probably blockers for an initial review, >> and might discourage contributions by making the initial hurdles appear >> higher. > > > It is accurate Benedict. There's past conversations at the foundation level > (+legal) about whether this agreement needed to be made explicitly (at the > time integration with github was being accepted). The verdict was that it > does not need to be explicit when contributing to existing files, because > those files are already copyright to the ASF and the contributor is not > requesting any change to that. > > When a contribution adds new files we move towards requiring them to sign a > (i)CLA. > But even, for simple contributions, this can be tackled implicitly, if fixing > any rat errors is on them. If the contributor puts the license header onto > the new files, the license includes reference to the copyright owner (being > the ASF). > > I see no harm in providing this information. With a preference as it is just > as information (not a checkbox). It's a soft opinion, but I suspect the > majority of PRs will be from folk that know all this already and the > checkboxes will be ignored. >
Re: [Proposal] add pull request template
> 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 that we point new contributors to the getting > started page which should cover these details. They need to go through it > once and not with each and every PR. > Yeah, totally agree.
Re: dtests to reproduce the schema disagreement
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 than going through coordinated path Hope this helps On Fri, Aug 12, 2022, at 8:30 PM, Cheng Wang via dev wrote: > Thank you, Jeff, now it works for me and I can reproduce a schema > disagreement. > The testing logic is like: > On node 1: > start the node 1 > create table > shutdown the node 1 > > Node node 2: > start the node 1 > create table > shutdown the node 2 > > Then startup the two nodes and check the schema version Id > > Now it seems that with the deterministic table id, the schema versions on the > two nodes were different initially, even though table ids are the same, and > they reached an agreement at some point. Is it as expected? > > I am just wondering, is there any other way to re-sync the shema versions > without restarting the node, cause I feel that shutdown/start is quite > expensive and flaky since the schema migration is a background task? > > Thanks > Cheng > > On Tue, Aug 9, 2022 at 12:12 PM Jeff Jirsa wrote: >> Stop node 1 before you start node 2, essentially mocking a full network >> partition. >> >> >> >> On Tue, Aug 9, 2022 at 11:57 AM Cheng Wang via dev >> wrote: >>> Thank you, Aleksey, >>> Yes, I have tried this approach, the problem is there is a timing window >>> that node 1 runs the CREATE TABLE while node 2 is down, and then we bring >>> up the node 2 and it may receive the gossip from node 1 at startup, and the >>> CREATE TABLE will fail on node 2 since the table already exists? >>> >>> >>> >>> On Tue, Aug 9, 2022 at 4:48 AM Aleksey Yeshchenko wrote: The absolute easiest way would be to down one of the two nodes first, run CREATE TABLE on the live node, shut it down, get the other one up, and run the same CREATE TABLE there, the bring up the down node. > On 9 Aug 2022, at 07:48, Konstantin Osipov via dev > wrote: > > * Cheng Wang via dev [22/08/09 09:43]: > >> I am working on improving the schema disagreement issue. I need some >> dtests >> which can reproduce the schema disagreement. Anyone know if there are >> any >> existing tests for that? Or something similar? > > cassandra-10250 is a good start. > > -- > Konstantin Osipov, Moscow, Russia
Re: Cassandra project status update 2022-08-17
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 green ci-cassandra runs? We don't have people volunteering for the build lead role so we don't consistently have tickets created for flaky or non-flaky test failures, thus we can't use that as a gatekeeper IMO as it's non-deterministic. Using "no non-flaky failures in butler (i.e. ci-cassandra + history analysis)" should shore that up. We also need a more rigorous designation for flaky vs. non-flaky in our tickets outside an informal practice of adding that to the Summary. I think a simple metric for "is something flaky" is "does it only fail once in the butler history (of 15 or so builds)". We can then filter out our kanban to reflect that as well (flaky tests to their own swimlane as they're "iffy" as RC blockers; it'd technically be a roll of the dice as to whether any flake on the 3 consecutive runs we need to get green to release... which I don't love ;) ). > We did something similar last time, this would be the same exception to the > rules, rules we continue to get closer to. If we did something similar last time and this is the same exception to the rules, I don't think we're getting closer to satisfying those rules are we? i.e. I think we should consider revising the rules formally to match the above metrics that are a little fuzzier and more tolerant to the current (and richly historical!) reality of our CI environment. Would save us a lot of back and forth on subsequent releases. :) ~Josh On Thu, Aug 18, 2022, at 1:24 AM, Berenguer Blasi wrote: > +1 to Mick's points. > > Also notice in circle 4.1 green runs are the norm lately imo. Yes it's not > the official CI but it helps build an overall picture of improvement towards > green CI. On jenkins, if you check the latest 4.1 runs, <5-ish failures per > run are starting to be common and those that don't are known failures being > worked on (CAS i.e.), infra or flakies taking you back to the <5-ish > failures. So overall, if I am not missing anything, the signal among the > infra and flaky noise is pretty good. > > Regards > > On 17/8/22 22:50, Ekaterina Dimitrova wrote: >> +1, I second Mick on both points. >> >> On Wed, 17 Aug 2022 at 16:23, Mick Semb Wever wrote: We're down from 13 tickets blocking 4.1 beta down to 7: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455. As mentioned above, we have some test failures w/out tickets so that 7 is probably closer realistically to the previous count. >>> >>> >>> I suggest we move to beta when all non-flaky-test tickets are resolved and >>> we get our first green ci-cassandra run. >>> And I suggest we move to rc when we get three consecutive green runs. >>> >>> We did something similar last time, this would be the same exception to the >>> rules, rules we continue to get closer to. >>> >>> An alternative is to replace "green" with "builds with only non-regression >>> and infra-caused failures". >>> >>> - It's pretty expensive and painful to defer cleaning up CI to the end of the release cycle >>> >>> >>> This^
Re: [Proposal] add pull request template
> 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 some other such useless commit message, then have to dig into the git integration and history, then figure out which merge commits were real and which were -s ours and silently changed, etc. So about those merge commits... ;) Anyway - longer-form commit messages (that we also propagate into merge commits and also indicate when a merge commit makes material changes to the base branch diff) would be a *large* quality of life improvement as this codebase continues to mature IMO. On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: > That's not accurate. The ASF requires that any significant contribution > requires a i(CLA), committer or not. Is there any guidance in the ASF docs as to what qualifies as "significant"? This seems like stuff we could document pretty trivially as a project and maybe link from the PR template. The more we can encourage and enable folks to independently work on something and pull the trigger on contributing to the project, the better.
Re: Cassandra project status update 2022-08-17
> 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, Brandon On Thu, Aug 18, 2022 at 9:31 AM Josh McKenzie wrote: > > So move to beta when: > > all non-flaky test *failures* (NOT tickets, see below) are resolved > We get a green ci-cassandra run > > Move to rc when: > > Three consecutive green runs in ci-cassandra > > Release when: > > All rc tickets are closed > Some time-based gate maybe? > Three more consecutive green ci-cassandra runs? > > > We don't have people volunteering for the build lead role so we don't > consistently have tickets created for flaky or non-flaky test failures, thus > we can't use that as a gatekeeper IMO as it's non-deterministic. Using "no > non-flaky failures in butler (i.e. ci-cassandra + history analysis)" should > shore that up. We also need a more rigorous designation for flaky vs. > non-flaky in our tickets outside an informal practice of adding that to the > Summary. > > I think a simple metric for "is something flaky" is "does it only fail once > in the butler history (of 15 or so builds)". > > We can then filter out our kanban to reflect that as well (flaky tests to > their own swimlane as they're "iffy" as RC blockers; it'd technically be a > roll of the dice as to whether any flake on the 3 consecutive runs we need to > get green to release... which I don't love ;) ). > > We did something similar last time, this would be the same exception to the > rules, rules we continue to get closer to. > > If we did something similar last time and this is the same exception to the > rules, I don't think we're getting closer to satisfying those rules are we? > i.e. I think we should consider revising the rules formally to match the > above metrics that are a little fuzzier and more tolerant to the current (and > richly historical!) reality of our CI environment. > > Would save us a lot of back and forth on subsequent releases. :) > > ~Josh > > On Thu, Aug 18, 2022, at 1:24 AM, Berenguer Blasi wrote: > > +1 to Mick's points. > > Also notice in circle 4.1 green runs are the norm lately imo. Yes it's not > the official CI but it helps build an overall picture of improvement towards > green CI. On jenkins, if you check the latest 4.1 runs, <5-ish failures per > run are starting to be common and those that don't are known failures being > worked on (CAS i.e.), infra or flakies taking you back to the <5-ish > failures. So overall, if I am not missing anything, the signal among the > infra and flaky noise is pretty good. > > Regards > > On 17/8/22 22:50, Ekaterina Dimitrova wrote: > > +1, I second Mick on both points. > > On Wed, 17 Aug 2022 at 16:23, Mick Semb Wever wrote: > > We're down from 13 tickets blocking 4.1 beta down to 7: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455. > As mentioned above, we have some test failures w/out tickets so that 7 is > probably closer realistically to the previous count. > > > > I suggest we move to beta when all non-flaky-test tickets are resolved and we > get our first green ci-cassandra run. > And I suggest we move to rc when we get three consecutive green runs. > > We did something similar last time, this would be the same exception to the > rules, rules we continue to get closer to. > > An alternative is to replace "green" with "builds with only non-regression > and infra-caused failures". > > > > - It's pretty expensive and painful to defer cleaning up CI to the end of the > release cycle > > > > This^ > >
Re: [Proposal] add pull request template
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 this should be pretty easy to incorporate into the workflow? On Thu, 18 Aug 2022 at 16:36, Josh McKenzie 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 continue to respect it!) and > I see "merge 3.11 into trunk" or some other such useless commit message, then > have to dig into the git integration and history, then figure out which merge > commits were real and which were -s ours and silently changed, etc. > > So about those merge commits... ;) > > Anyway - longer-form commit messages (that we also propagate into merge > commits and also indicate when a merge commit makes material changes to the > base branch diff) would be a large quality of life improvement as this > codebase continues to mature IMO. > > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: > > That's not accurate. The ASF requires that any significant contribution > requires a i(CLA), committer or not. > > Is there any guidance in the ASF docs as to what qualifies as "significant"? > This seems like stuff we could document pretty trivially as a project and > maybe link from the PR template. > > The more we can encourage and enable folks to independently work on something > and pull the trigger on contributing to the project, the better.
Re: Cassandra project status update 2022-08-17
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 project or folks who haven't worked in the CI space that want to pitch in to push a release across the line right now don't have any guidance as to how to classify things. 3. Unless that classifications is more rigorous, rules like "no non-flaky test failures" don't actually mean the same thing to everyone on the project if we don't have a shared definition of what we're considering "flaky". Also, one other data point in favor of a simple frequency heuristic is that if these tests are flaking on ci-cassandra but not flaking on circleci, that's more evidence that they're *likely* test environment + authoring failures rather than product failures. On Thu, Aug 18, 2022, at 10:36 AM, Brandon Williams wrote: > > 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, > Brandon > > On Thu, Aug 18, 2022 at 9:31 AM Josh McKenzie wrote: > > > > So move to beta when: > > > > all non-flaky test *failures* (NOT tickets, see below) are resolved > > We get a green ci-cassandra run > > > > Move to rc when: > > > > Three consecutive green runs in ci-cassandra > > > > Release when: > > > > All rc tickets are closed > > Some time-based gate maybe? > > Three more consecutive green ci-cassandra runs? > > > > > > We don't have people volunteering for the build lead role so we don't > > consistently have tickets created for flaky or non-flaky test failures, > > thus we can't use that as a gatekeeper IMO as it's non-deterministic. Using > > "no non-flaky failures in butler (i.e. ci-cassandra + history analysis)" > > should shore that up. We also need a more rigorous designation for flaky > > vs. non-flaky in our tickets outside an informal practice of adding that to > > the Summary. > > > > I think a simple metric for "is something flaky" is "does it only fail once > > in the butler history (of 15 or so builds)". > > > > We can then filter out our kanban to reflect that as well (flaky tests to > > their own swimlane as they're "iffy" as RC blockers; it'd technically be a > > roll of the dice as to whether any flake on the 3 consecutive runs we need > > to get green to release... which I don't love ;) ). > > > > We did something similar last time, this would be the same exception to the > > rules, rules we continue to get closer to. > > > > If we did something similar last time and this is the same exception to the > > rules, I don't think we're getting closer to satisfying those rules are we? > > i.e. I think we should consider revising the rules formally to match the > > above metrics that are a little fuzzier and more tolerant to the current > > (and richly historical!) reality of our CI environment. > > > > Would save us a lot of back and forth on subsequent releases. :) > > > > ~Josh > > > > On Thu, Aug 18, 2022, at 1:24 AM, Berenguer Blasi wrote: > > > > +1 to Mick's points. > > > > Also notice in circle 4.1 green runs are the norm lately imo. Yes it's not > > the official CI but it helps build an overall picture of improvement > > towards green CI. On jenkins, if you check the latest 4.1 runs, <5-ish > > failures per run are starting to be common and those that don't are known > > failures being worked on (CAS i.e.), infra or flakies taking you back to > > the <5-ish failures. So overall, if I am not missing anything, the signal > > among the infra and flaky noise is pretty good. > > > > Regards > > > > On 17/8/22 22:50, Ekaterina Dimitrova wrote: > > > > +1, I second Mick on both points. > > > > On Wed, 17 Aug 2022 at 16:23, Mick Semb Wever wrote: > > > > We're down from 13 tickets blocking 4.1 beta down to 7: > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455. > > As mentioned above, we have some test failures w/out tickets so that 7 is > > probably closer realistically to the previous count. > > > > > > > > I suggest we move to beta when all non-flaky-test tickets are resolved and > > we get our first green ci-cassandra run. > > And I suggest we move to rc when we get three consecutive green runs. > > > > We did something similar last time, this would be the same exception to the > > rules, rules we continue to get closer to. > > > > An alternative is to replace "green" with "builds with only non-regression > > and infra-caused failures". > > > > > > > > - It's pretty expensive and painful to defer cleaning up CI to the end of > > the release cycle > > > > > > > > This^ > > > > >
Re: [Proposal] add pull request template
> 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 Miklosovic wrote: > 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 this should be pretty easy to incorporate into > the workflow? > > On Thu, 18 Aug 2022 at 16:36, Josh McKenzie 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 continue to respect it!) > > and I see "merge 3.11 into trunk" or some other such useless commit > > message, then have to dig into the git integration and history, then figure > > out which merge commits were real and which were -s ours and silently > > changed, etc. > > > > So about those merge commits... ;) > > > > Anyway - longer-form commit messages (that we also propagate into merge > > commits and also indicate when a merge commit makes material changes to the > > base branch diff) would be a large quality of life improvement as this > > codebase continues to mature IMO. > > > > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: > > > > That's not accurate. The ASF requires that any significant contribution > > requires a i(CLA), committer or not. > > > > Is there any guidance in the ASF docs as to what qualifies as > > "significant"? This seems like stuff we could document pretty trivially as > > a project and maybe link from the PR template. > > > > The more we can encourage and enable folks to independently work on > > something and pull the trigger on contributing to the project, the better. >
Re: [Proposal] add pull request template
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 merging / committing I do not thing this approach applies to anything more complicated than a nice linear commit history. On Thu, 18 Aug 2022 at 16:46, Josh McKenzie wrote: > > 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 Miklosovic wrote: > > 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 this should be pretty easy to incorporate into > the workflow? > > On Thu, 18 Aug 2022 at 16:36, Josh McKenzie 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 continue to respect it!) > > and I see "merge 3.11 into trunk" or some other such useless commit > > message, then have to dig into the git integration and history, then figure > > out which merge commits were real and which were -s ours and silently > > changed, etc. > > > > So about those merge commits... ;) > > > > Anyway - longer-form commit messages (that we also propagate into merge > > commits and also indicate when a merge commit makes material changes to the > > base branch diff) would be a large quality of life improvement as this > > codebase continues to mature IMO. > > > > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: > > > > That's not accurate. The ASF requires that any significant contribution > > requires a i(CLA), committer or not. > > > > Is there any guidance in the ASF docs as to what qualifies as > > "significant"? This seems like stuff we could document pretty trivially as > > a project and maybe link from the PR template. > > > > The more we can encourage and enable folks to independently work on > > something and pull the trigger on contributing to the project, the better. > >
Re: [Proposal] add pull request template
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 in the merge commits? I can not be worse than it currently is. If we now say what a commit message should look like for "normal" commits, why would it be any different on merge commits? On Thu, 18 Aug 2022 at 16:46, Josh McKenzie wrote: > > 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 Miklosovic wrote: > > 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 this should be pretty easy to incorporate into > the workflow? > > On Thu, 18 Aug 2022 at 16:36, Josh McKenzie 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 continue to respect it!) > > and I see "merge 3.11 into trunk" or some other such useless commit > > message, then have to dig into the git integration and history, then figure > > out which merge commits were real and which were -s ours and silently > > changed, etc. > > > > So about those merge commits... ;) > > > > Anyway - longer-form commit messages (that we also propagate into merge > > commits and also indicate when a merge commit makes material changes to the > > base branch diff) would be a large quality of life improvement as this > > codebase continues to mature IMO. > > > > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: > > > > That's not accurate. The ASF requires that any significant contribution > > requires a i(CLA), committer or not. > > > > Is there any guidance in the ASF docs as to what qualifies as > > "significant"? This seems like stuff we could document pretty trivially as > > a project and maybe link from the PR template. > > > > The more we can encourage and enable folks to independently work on > > something and pull the trigger on contributing to the project, the better. > >
Re: [Proposal] add pull request template
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 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 some other such useless commit message, then > have to dig into the git integration and history, then figure out which merge > commits were real and which were -s ours and silently changed, etc. > > So about those merge commits... ;) > > Anyway - longer-form commit messages (that we also propagate into merge > commits and also indicate when a merge commit makes material changes to the > base branch diff) would be a large quality of life improvement as this > codebase continues to mature IMO. > >> On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: >> That's not accurate. The ASF requires that any significant contribution >> requires a i(CLA), committer or not. > Is there any guidance in the ASF docs as to what qualifies as "significant"? > This seems like stuff we could document pretty trivially as a project and > maybe link from the PR template. > > The more we can encourage and enable folks to independently work on something > and pull the trigger on contributing to the project, the better.
Re: [Proposal] add pull request template
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 some other such useless commit > message, then have to dig into the git integration and history, then figure > out which merge commits were real and which were -s ours and silently > changed, etc. > > So about those merge commits... ;) > The beef I have with this is it's just not that difficult: just look at the parent 2 commit of the merge. ``` git log -n1 ^2 ``` (you can also use `git log --follow .` if you like history without merge commits) > (… also propagate into merge commits and also indicate when a merge > commit makes material changes to the base branch diff) > Beef aside (take it w/ a grain of salt!), this is a good idea. Enforcing it is another matter, and what about all existing history… 🤷🏻♀️ Having different merge strategies in our history would be worse IMHO. > That's not accurate. The ASF requires that any significant contribution > requires a i(CLA), committer or not. > > Is there any guidance in the ASF docs as to what qualifies as > "significant"? This seems like stuff we could document pretty trivially as > a project and maybe link from the PR template. > Nothing qualifies it AFAIK. The Apache License contains the following: "Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions." Good reads: https://lists.apache.org/thread/0mytpqj7too29bj90yz65rggdv7gd35d and https://lists.apache.org/thread/vob27jog5qzrr9m2gz0063log3v6gkc1 In the second, Ted writes "If it is large enough or clever enough to be hard to replicate you should probably ask for a more formal record of agreement to the license."
Re: [Proposal] add pull request template
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 continue to respect it!) and I see "merge 3.11 into trunk" or some other such useless commit message, then have to dig into the git integration and history, then figure out which merge commits were real and which were -s ours and silently changed, etc. So about those merge commits... ;) The beef I have with this is it's just not that difficult: just look at the parent 2 commit of the merge. ``` |git log -n1 ^2| ``` (you can also use `git log --follow .` if you like history without merge commits) There's `git merge --log` which provides a short-form log in the merge commit.
Re: [Proposal] add pull request template
> 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) ?
Re: [Proposal] add pull request template
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 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) ? > > > >
Re: [Proposal] add pull request template
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 different merge strategies in our history would be worse IMHO. I disagree pretty strongly here. I think an "all commits are chronologically applied to the branch, no changes are hidden inside merge commits" approach is immediately intuitive; people would only have to know the old strategy when they stumble across merge commits which is explicitly no worse than our status quo. 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. :) On Thu, Aug 18, 2022, at 12:07 PM, Avi Kivity via dev wrote: > > > 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 continue to respect it!) >>> and I see "merge 3.11 into trunk" or some other such useless commit >>> message, then have to dig into the git integration and history, then figure >>> out which merge commits were real and which were -s ours and silently >>> changed, etc. >>> >>> So about those merge commits... ;) >> >> >> The beef I have with this is it's just not that difficult: just look at the >> parent 2 commit of the merge. >> >> ``` >> `git log -n1 ^2` >> ``` >> (you can also use `git log --follow .` if you like history without merge >> commits) >> > > > There's `git merge --log` which provides a short-form log in the merge commit. > > >
unsubscribe
-- Best Regards, Ajai Joy
Re: [Proposal] add pull request template
> > 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-only so we can evaluate them for real.
Re: [Proposal] add pull request template
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 can be justified by those who are able, if there’s a chance it will be discarded? I can’t see us maintaining a bifurcated process, where some patches go through automation and others don’t, so if we don’t change the merge strategy that work would presumably end up wasted. > On 18 Aug 2022, at 18:53, Mick Semb Wever wrote: > > >> 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-only so we > can evaluate them for real.
Re: [Proposal] add pull request template
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’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 can be justified by those who are able, if there’s a > chance it will be discarded? I can’t see us maintaining a bifurcated process, > where some patches go through automation and others don’t, so if we don’t > change the merge strategy that work would presumably end up wasted. > > On 18 Aug 2022, at 18:53, Mick Semb Wever wrote: > > >> >> 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-only so we > can evaluate them for real.
Re: [Proposal] add pull request template
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 can produce separate PRs for each branch, that can be merged independently via the GitHub API. The downside of this is that there are no merge commits, while one upside of this is that there are no merge commits. > On 18 Aug 2022, at 20:20, Stefan Miklosovic > wrote: > > 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’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 can be justified by those who are able, if there’s >> a chance it will be discarded? I can’t see us maintaining a bifurcated >> process, where some patches go through automation and others don’t, so if we >> don’t change the merge strategy that work would presumably end up wasted. >> >> On 18 Aug 2022, at 18:53, Mick Semb Wever wrote: >> >> >>> >>> 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-only so we >> can evaluate them for real.
Re: [Proposal] add pull request template
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 we have. TBH 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. However, it does make sense. On Thu, 18 Aug 2022 at 21:28, Benedict wrote: > > 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 can produce separate PRs for > each branch, that can be merged independently via the GitHub API. The > downside of this is that there are no merge commits, while one upside of this > is that there are no merge commits. > > On 18 Aug 2022, at 20:20, Stefan Miklosovic > wrote: > > 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’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 can be justified by those who are able, if there’s a > chance it will be discarded? I can’t see us maintaining a bifurcated process, > where some patches go through automation and others don’t, so if we don’t > change the merge strategy that work would presumably end up wasted. > > > On 18 Aug 2022, at 18:53, Mick Semb Wever wrote: > > > > > > 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-only so we > can evaluate them for real.
Re: [Proposal] add pull request template
> 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 things and have it equally apply on this project. Perils of being a mature long-lived project I suspect. I'm all for us doing the hard work of introspecting on how we do things and changing them to improve or match industry standards where applicable. On Thu, Aug 18, 2022, at 3:33 PM, Stefan Miklosovic wrote: > 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 we have. TBH 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. > However, it does make sense. > > On Thu, 18 Aug 2022 at 21:28, Benedict wrote: > > > > 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 can produce separate PRs for > > each branch, that can be merged independently via the GitHub API. The > > downside of this is that there are no merge commits, while one upside of > > this is that there are no merge commits. > > > > On 18 Aug 2022, at 20:20, Stefan Miklosovic > > wrote: > > > > 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’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 can be justified by those who are able, if > > there’s a chance it will be discarded? I can’t see us maintaining a > > bifurcated process, where some patches go through automation and others > > don’t, so if we don’t change the merge strategy that work would presumably > > end up wasted. > > > > > > On 18 Aug 2022, at 18:53, Mick Semb Wever wrote: > > > > > > > > > > > > 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-only so we > > can evaluate them for real. >
[ANNOUNCE] Apache Cassandra 4.0.6 test artifact available
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 and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/4.0.6/ A vote of this test build will be initiated within the next couple of days. [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.6-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.6-tentative
Re: [ANNOUNCE] Apache Cassandra 4.0.6 test artifact available
The test build of Cassandra 4.0.6 is available. > > sha1: > The sha is eb2375718483f4c360810127ae457f2a26ccce67
New episode of the Apache Cassandra(R) Corner Podcast!
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 22nd. If anyone should have any questions, comments, or if you want to be a guest, please reach out to me. For my guest pipeline, I have recording sessions scheduled with: - Otavio Santana (Java Champion and Open Source Committer w/ the Eclipse Foundation) - Sarma Pydipally (Udemy Instructor, Principal Engineer w/ Verizon) So I should have a good flow of episodes for the next couple of weeks. Thanks everyone! Aaron Ploetz
Re: [Proposal] add pull request template
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 😇 On Thu, Aug 18, 2022 at 9:10 PM Josh McKenzie wrote: > 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 things and > have it equally apply on this project. > > Perils of being a mature long-lived project I suspect. I'm all for us > doing the hard work of introspecting on how we do things and changing them > to improve or match industry standards where applicable. > > On Thu, Aug 18, 2022, at 3:33 PM, Stefan Miklosovic wrote: > > 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 we have. TBH 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. > However, it does make sense. > > On Thu, 18 Aug 2022 at 21:28, Benedict > wrote: > > > > 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 can produce separate PRs for > each branch, that can be merged independently via the GitHub API. The > downside of this is that there are no merge commits, while one upside of > this is that there are no merge commits. > > > > On 18 Aug 2022, at 20:20, Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> wrote: > > > > 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’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 can be justified by those who are able, if > there’s a chance it will be discarded? I can’t see us maintaining a > bifurcated process, where some patches go through automation and others > don’t, so if we don’t change the merge strategy that work would presumably > end up wasted. > > > > > > On 18 Aug 2022, at 18:53, Mick Semb Wever wrote: > > > > > > > > > > > > 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-only so > we can evaluate them for real. > > >
