Re: [DISCUSS] Releasable trunk and quality

[bened...@apache.org]

So, one advantage of merge commits is that review of each branch is potentially 
easier, as the merge commit helps direct the reviewer’s attention. However, in 
my experience most of the focus during review is to the main branch anyway. 
Having separate tickets to track backports, and permitting them to occur out of 
band, could improve the quality of review. We can also likely synthesise the 
merge commits for the purpose of review using something like

git checkout patch-4.0~1
git checkout -b patch-4.0-review
git merge -s ours patch-4.1~1
git merge --no-commit patch-4.1
git checkout patch-4.0 .
git commit


From: bened...@apache.org 
Date: Wednesday, 5 January 2022 at 21:07
To: Mick Semb Wever 
Cc: dev 
Subject: Re: [DISCUSS] Releasable trunk and quality

> 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 3 or 4 diffs, none of which tell the 
whole story (and all of which bleed legacy details of earlier branches). This 
is a genuine significant pain point when doing archaeology, something I and 
others do quite frequently, and a large part of why I want to see them gone.

> Folk forget to pull, rebase, then go to push and realise one of their patches 
> on a branch needs rebasing and rework. That rework may make them reconsider 
> the patch going to the other branches too.

Conversely, this is exceptionally painful when maintaining branches and forks, 
and I can attest to the pain of maintaining these branches so they may be 
committed atomically to having wasted literal person-weeks in my time on the 
project. I do not recall experiencing a significant benefit in return.

> do i have to start text searching the git history

Yes. This is so simple as to be a non-issue - surely you must search git log 
semi-regularly? It is a frequent part of the job of developing against the 
project in my experience.

> Developing patch on hardest branch first, then working on each softer branch. 
> I don't know how important this is, but I have found it a useful practice 
> that encourages smaller, more precise patches overall.

I don’t think this strategy determines which branch is first developed against. 
However, if it did, it would seem to me to be a clear mark against the current 
system, which incentivises fully developing against the oldest version before 
forward-porting its entirety. Developing primarily against the most recent 
branch incentivises back-porting more minimal versions of the work, once the 
scope of the work is fully understood.

Re: [DISCUSS] Releasable trunk and quality

[Joshua McKenzie]

>
> 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?

I've been noodling on this a bit; I think it's a question of degree. When I
see a merge commit my intuitive expectation is "it takes the context of
application of diff over there and moves it over here", not "it claims to
have taken the context from over there but actually only takes it
symbolically (-s ours), and all the changes are manually applied by a
separate motion here".

Applying hand-crafted patches to each branch w/out "merge -s ours" is more
_honest_ in the case where we can't merge between branches. I think the
status quo is largely fine if you have a trivial change and a merge commit
between branches, but I also find trivial patch application uninteresting
and simple enough that either merge strategy is fine. All this said, I am
*definitively* not advocating we have different merge strategies based on
the size of a patch and whether it necessitates the -s ours, more trying to
explore the nuance behind my reaction to the status quo.


On Thu, Jan 6, 2022 at 7:28 AM bened...@apache.org 
wrote:

> So, one advantage of merge commits is that review of each branch is
> potentially easier, as the merge commit helps direct the reviewer’s
> attention. However, in my experience most of the focus during review is to
> the main branch anyway. Having separate tickets to track backports, and
> permitting them to occur out of band, could improve the quality of review.
> We can also likely synthesise the merge commits for the purpose of review
> using something like
>
>
>
> git checkout patch-4.0~1
>
> git checkout -b patch-4.0-review
>
> git merge -s ours patch-4.1~1
>
> git merge --no-commit patch-4.1
>
> git checkout patch-4.0 .
>
> git commit
>
>
>
>
>
> *From: *bened...@apache.org 
> *Date: *Wednesday, 5 January 2022 at 21:07
> *To: *Mick Semb Wever 
> *Cc: *dev 
> *Subject: *Re: [DISCUSS] Releasable trunk and quality
>
>
>
> > 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 3 or 4 diffs, none of which
> tell the whole story (and all of which bleed legacy details of earlier
> branches). This is a genuine significant pain point when doing archaeology,
> something I and others do quite frequently, and a large part of why I want
> to see them gone.
>
>
>
> > Folk forget to pull, rebase, then go to push and realise one of their
> patches on a branch needs rebasing and rework. That rework may make them
> reconsider the patch going to the other branches too.
>
>
>
> Conversely, this is exceptionally painful when maintaining branches and
> forks, and I can attest to the pain of maintaining these branches so they
> may be committed atomically to having wasted literal person-weeks in my
> time on the project. I do not recall experiencing a significant benefit in
> return.
>
>
>
> > do i have to start text searching the git history
>
>
>
> Yes. This is so simple as to be a non-issue - surely you must search git
> log semi-regularly? It is a frequent part of the job of developing against
> the project in my experience.
>
>
>
> > Developing patch on hardest branch first, then working on each softer
> branch. I don't know how important this is, but I have found it a useful
> practice that encourages smaller, more precise patches overall.
>
>
>
> I don’t think this strategy determines which branch is first developed
> against. However, if it did, it would seem to me to be a clear mark against
> the current system, which incentivises fully developing against the oldest
> version before forward-porting its entirety. Developing primarily against
> the most recent branch incentivises back-porting more minimal versions of
> the work, once the scope of the work is fully understood.
>
>
>
>
>
>
>

Re: [DISCUSS] Releasable trunk and quality

[Henrik Ingo]

On Wed, Jan 5, 2022 at 10:38 PM Mick Semb Wever  wrote:

> +(?) Is the devil we know
>>
>
> + Bi-directional relationship between patches showing which branches it
> was applied to (and how).  From the original commit or any of the merge
> commits I can see which branches, and where the original commit, was
> applied. (See the mongo example from Henrik, how do I see which other
> branches the trunk commit was committed to? do i have to start text
> searching the git history or going through the ticket system :-(
>

Just to answer the question, I'm obviously not that impacted by how
Cassandra commits happen myself...

Maybe a thing I wouldn't copy from MongoDB is that their commit messages
are often one liners and yes you need to look up the jira ticket to read
what the commit does. A feature of this approach is that the jira ticket
can be edited later. But personally I always hated that the commit itself
didn't contain a description.

Other than that, yes I would grep or otherwise search for the ticket id or
githash, which must be included in the cherry picked commit. It never
occurred to me someone wouldn't like this. Note that the stable branches
eventually only get a handful of patches per month, so even just reading
the git log gives a nice overview. If anything the "merge branch X into Y"
always confuse me as I have no idea what that does.

As for verifying that each branch was patched, if you adhere to committing
first to trunk, then in descending order to each stable branch, you can
just check the oldest branch to verify the chain. Not everyone followed
this style, but I would always append the cherry pick message, so that the
last commit (to the oldest stable branch) would contain the chain of
githashes all the way to trunk.

henrik

-- 

Henrik Ingo

+358 40 569 7354 <358405697354>

[image: Visit us online.]   [image: Visit us on
Twitter.]   [image: Visit us on YouTube.]

  [image: Visit my LinkedIn profile.]