Re: git: 000aad3d093a - stable/12 - loader: allocate properly aligned buffer for network packet

On Thu, Oct 7, 2021 at 8:26 AM Ian Lepore <ian@freebsd.org> wrote:

> On Thu, 2021-10-07 at 06:50 +0000, Alexey Dokuchaev wrote:
> > On Thu, Oct 07, 2021 at 01:20:05AM -0500, Kyle Evans wrote:
> > > On Thu, Oct 7, 2021 at 1:06 AM Alexey Dokuchaev wrote:
> > > > On Thu, Oct 07, 2021 at 03:37:42AM +0000, Kyle Evans wrote:
> > > > > commit 000aad3d093a376bb1104a284b4102149db43155
> > > > >
> > > > >  loader: allocate properly aligned buffer for network packet
> > > > >
> > > > >  Use memalign(4, size) to ensure we have properly aligned
> > > > > buffer.
> > > > >
> > > > >  (cherry picked from commit
> > > > > 659bf32dfc595b6cd6aeda7f05cb57872c64d2d1)
> > > >
> > > > I don't understand, so this is a merge of the commit from master
> > > > (main) to
> > > > stablle/12 which had then been reverted?  So why do the merge in
> > > > the first
> > > > place?
> > >
> > > Because commit + revert pairs are noise in the MFC tracker that
> > > distracts from actual candidates for merging.
> >
> > Sounds like MFC tracker should be fixed then, as now it is noise in
> > the tool (tracker) vs. noise in the branch.  Tools come and go, and
> > code stays forever.
> >
> > ./danfe
>
> I completely disagree, and used to do this kind of mfc even before the
> nifty mfc tracker came along.  I see merging to older branches as a
> process of replaying the commits that happened on the main branch, and
> if that involves reverting and recommitting, I replay those too.
>

With git, though, we can squash the commits together and include muliple
cherry-picked lines. This can be part of the replaying process and git
supports
us improving our process for things like this.

Now, one could argue that the MFC track could also be improved, and that's
true. However, there's other tools than just the MFC tracker that would need
updating and some careful thought to balance all the concerns needs to take
place, I think.

What Kyle did is fine. It isn't terrible. Neither is it perfect, but it is
well within
the range of acceptable choices we have today. At the same time, it does
highlight we could do a bit better, perhaps. Absent any guidance, though,
I don't think we can expect much better.

I'll add this as a possible area to explore in the git working group.

Warner