U-Boot btrfs implementation - will there by syncing?

["Marek Behún" <kabel@kernel.org>]

Hello Qu and others,

one of the points of Qu's reimplementation of U-Boot's btrfs code that
made it somehow synced with btrfs-progs, was that the old
implementation was, quote

  pretty different from btrfs-progs nor kernel, making it pretty hard to
  sync code between different projects

Another point was that afterwards Qu wanted to bring some of the missing
btrfs features into U-Boot, since they should be much easier to
implement after the reimplementation.

I was looking at current btrfs-progs, and noticed that there were many
changes since then, but only one or two were ever synced to U-Boot.

I would like to know if Qu, or anyone else, is planning to do this
code-syncing, and maybe implement some of the missing features?

The reason I am asking this is that in the meantime I've reached the
opinion that the idea of code-syncing in this sense almost never really
works. It is usually proposed by one person who ports the code from
another project, and then keeps it synced for a time, but then stops
doing it because they have too much other work, or change employer, or
another reason.

It happened multiple times. One example is U-Boot's Hush shell, which
was imported from busybox, with the intention to keep it in sync, but
the reality is that U-Boot's implementation is now years (decade?) old,
and there were so many ad-hoc fixes done in U-Boot that currently the
only way to sync is basically to change the whole code (which will also
cause issues with existing user scripts, but maybe it should be done
anyway).

Another reason why I am writing this is that I think that with the
amount of work Qu put into that reimplementation last year, he could
have instead implemented some of the new features in the old
implementation and spend a similar amount of time doing that, and the
result would be those new features in U-Boot for over a year by now.

Also, I've come to the opinion that maybe two different and maintained
implementations are a good thing for such a project as a filesystem,
similar to how multiple implementations of C/C++ compiler are a good
thing.

For the last few months I was on-and-off thinking about whether it
would make sense to revert to the original implementation and then
implement some of the missing features. But it would not make sense if
Qu, or anyone else, is planning to do that code syncing and bringing of
new features from btrfs-progs, so that's why I am asking.

Please give your opinions, people.

Thanks.

Marek