Re: [PATCH v2] expand-on-first-boot: support resizing a btrfs root

["Roberto A. Foglietta" <roberto.foglietta@gmail.com>]

On Mon, 12 Dec 2022 at 16:24, Henning Schild <henning.schild@siemens.com> wrote:

>
> Joe, i had to rewrite your patch considerably. So i think i will change
> the authorship to myself. I would really like to give you the credits
> but am afraid to give you blame ... this whole expand story seems never
> ending ...
> So the patch will mention you, but likely not as author.
>

Thank you in advance for the mention. I wish to point out to you the
fact that supporting the btrfs is completely another issue than
triggering the udev to link the device and frankly speaking I do not
see the reason to keep the two things together. So, my ancestor patch
and the following development correctly address the btrfs support but
inherit the problem of failing when "${LAST_PART}" == "" which is a
completely another story because it depends on udev. Also the code to
trigger udev in order to create the devices links has been presented
here from another project of mine. So, the mention makes sense.

As a mere recap, this story should never have started at all. Because
there were two separate problems, no one of them was my duty to solve.
Moreover, the team got stuck into the idea of supporting every
filesystem on every platform: wrong approach. First separate legacy
from development, second fix a problem at time, third follows a
continuous improvement and continuous delivery model.

The btrfs support was not mandatory but suggested for the future due
to its intrinsic characteristics and the performance improvements
delivered into kernel v6.1. Your mandatory problem was to deal with
udev on a specific hardware platform and this was confused with a ext4
resizing failure - sometimes fails sometimes not depending the udev
timings (as far as I can remember) - so the btrfs got into the scene
as a suggestion to discard a software failure in resizing. If both
fail the problem is somewhere, in fact.

> but am afraid to give you blame

The only blame you can give to me is not being in charge of this at no
any time but trying to help without even having a piece of hardware to
make a test. In fact, the udev tests/code I did - I did on my
Christmas present for my nephew!

Best regards, R-