Re: [PATCH v8 00/20] Migrate to Bitbake 2.0

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

On Thu, 26 Jan 2023 at 20:59, Henning Schild <henning.schild@siemens.com> wrote:
>
> Am Thu, 26 Jan 2023 14:23:06 +0100
> schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>:
>
> > On Thu, 26 Jan 2023 at 08:29, Anton Mikanovich <amikan@ilbers.de>
> > wrote:
> > >
> > > 26/01/2023 01:43, Roberto A. Foglietta wrote:
> > > > On Wed, 25 Jan 2023 at 20:23, Anton Mikanovich <amikan@ilbers.de>
> > > > wrote:
> > > >> This patchset moves Isar to use Bitbake 2.0 branch.
> > > >>
> > > > Hi, how can I check which version I have previously integrated in
> > > > my branch?
> > > >
> > > > Thanks, R-
> > >
> > > Hello Roberto,
> > >
> > > $ cat bitbake/bin/bitbake | grep "__version__"
> > >
> >
> > Great, but this gives me the version of bitbake. I was interested in
> > the version of the patches. Because I have an old version but I do not
> > know which version and there is no versioning in any commit. So, I do
> > not know the version of the patchset and I have to find out to
> > understand if I need to apply this version immediately or I can wait.
>
> This is v8 as the cover letter says. If you already jumped on not
> merged code you should know which version you took.
>
> Needless to say that you should never take code that is not yet merged
> for more than "playing".
>

Experimenting is the proper word.

If I have to keep in my mind or in my notes all the versions of every
patch, then I am underusing git because it can do it for me.

About unmerged code, thanks for the suggestion.

The schroot migration improves performances, and I submit the patch to
complete it. The reproducibility could be interesting even if it does
not add any performance. For reproducibility, I sent a patch for
suggestions which in large part has been taken. Building the custom
packages is essential, and I submit the patch to use mount bind which
also brings reproducibility per default in my packages but I cannot
grant for others. The code for adding extra options to sbuild has been
submitted as a patch as well. Bitbakes 2 migration does not add
performances. Also that patchset carries a simple contribution of
mine. Very simple contribution which is the syntax conversion of some
files. Most of that conversion was obtained by the script which does
not cover 100% of the cases, anyway, Every performance gain with BB2
could be obtained also with the previous version. Because zstd
decompression excellent performances are limited by the I/O
performances and I have one of the fastest SSD on the market, so I can
say it for real. Its 13x gain could be obtained only when used
memory-to-memory like a browser does.

So, my experiment gives back something to the original project or at
least shows this attitude. By the way, my experiment is in such a mess
that no one can sell it at this stage of development but *I* can
easily fix it. Because I use git for keeping the versioning, I have
free space in my mind to keep the information to put order in my
experiments. This also explains why documenting the patches is not so
important for me but versioning is instead important. After all,
Leonardo Da Vinci was written with a mirror. A very easy trick but at
that time having a mirror was not so common and cheap. I am not saying
that I am LdV. I am saying that I learn by LdV. Just to clarify that
other people might have very good reasons to do things that we
consider weird from our perspective. Especially In open-source,
diversity acceptance would be a sign of universality.

It was long in writing but just to say in a brief summary: we have
enough to converge to a common base in the worst case and in the best,
well why worry about the best case? LOL

Best regards, R-