I think simple, consistent, reliable and unavoidable are *the* killer features
for QA. All features (give or take) of the industry standard approach of using
CI hooks to gate PR merge.
From: Joshua McKenzie
Date: Wednesday, 5 January 2022 at 14:53
To: dev
Subject: Re: [DISCUSS] Releasable trun
> If you see a merge commit in the history, isn't it normal to presume that it
> will contain the additional change for that branch for the parent commit
> getting merged in?
Sure, but it is exceptionally non-trivial to treat the work as a single diff in
any standard UX. In practice it becomes
> - hides changes inside the merge commit
>
This is what all merge commits do. If you see a merge commit in the
history, isn't it normal to presume that it will contain the additional
change for that branch for the parent commit getting merged in?
> - is exposed to race w/other committers acro
Could you note that in the wiki in the comments section Ekaterina?
https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=199530280&draftShareId=7c72c252-918c-456b-9859-7d12e8fa9309&;
Thanks!
On Tue, Jan 4, 2022 at 4:21 PM Ekaterina Dimitrova
wrote:
> Hey Josh,
> Thank you for le
> A wise man once said "Simple is a feature" ;)
For those unfamiliar, this was a reference to a sentiment Jonathan has
expressed over the years which I strongly agree with
https://issues.apache.org/jira/browse/CASSANDRA-6809?focusedCommentId=14102901&page=com.atlassian.jira.plugin.system.issuetabp
A wise man once said "Simple is a feature" ;)
Our current process (commit oldest, merge up or merge -s ours w/ --amend):
- is confusing for new contributors to understand
- hides changes inside the merge commit
- masks future ability to see things with git attribute on commits
- is exposed to race
