Re: Linux-libre 5.8 and beyond

[Alexandre Oliva]

Hello, Mark,

On Aug 25, 2020, Mark H Weaver <mhw@netris.org> wrote:

> Alexandre Oliva <lxoliva@fsfla.org> wrote:
>> On Aug 15, 2020, Mark H Weaver <mhw@netris.org> wrote:
>> 
>>> If I were to implement this, what would you suggest I do if the patches
>>> fail to apply
>> 
>> Look at the conflict presented by the rebase, and resolve the likely
>> freedom issue introduced at that point.
>> 
>>> if the result fails to match the next Linux-libre release?
>> 
>> Identify the intervening commit where code that got cleaned up
>> differently was introduced or removed and make the change to the
>> deblobbing at that point; rinse and repeat.

> In other words, your proposed approach cannot be done automatically in
> the general case.  Do you see how this is a problem?

Remember a few emails ago when *you* argued that the changes to the
deblobbing scripts were so infrequent that it would do no harm to use
the scripts for an earlier release, without waiting for us to check that
they work for a newer one?

How come now the very same circumstances have become so frequent as to
be a problem?


You see, the cases in which there would be patch conflicts and need for
manual resolution are those in which the cleanups made by older scripts
are no longer enough to clean up subsequent trees.

Most of these are cases in which manual intervention is required to
adjust the scripts.  But you wish to use the scripts to clean up
intervening commits that it was never tested to work on and that it may
actually fail on, leaving non-FSDG bits in place, *instead* of using a
procedure that will reliably tell you about the IYO rare cases in which
manual intervention is required.

You dismiss our automated and manual verifications, you used to use
outdated scripts, but you can't be bothered to run a simple procedure to
check that there aren't freedom issues introduced in an upstream stable
release, and to make the required manual adjustments to keep the builds
FSDG-compliant?

Heck, I'll be glad to publish, upon request, in the Linux-libre git
repo, a verified-FSDG incremental stable release branch, i.e., a branch
starting from one release and ending at a tree identical to that of a
subsequent release in the same stable branch.  Then you can point users
at that branch for bisecting within that range.

Should that be as seamless as I expect it to be, I might even start
doing that regularly, for all stable releases, as an incremental step
towards the git repo with the cleaned-up commit history of Linux
development.


> If a Guix user reports that one of their devices stopped working in
> Linux-libre-5.4.34, I'd like to enable them to easily build deblobbed
> kernels at intermediate commits on the upstream stable/linux-5.4.y
> branch.

That amounts to referring users to a non-Free source repo; that's not
desirable per the FSDG.  If we want to enable them to bisect for us, we
should offer them our own cleaned-up history.

> With the present approach, I can provide a simple Guix recipe
> to do this automatically.

... and quite prone to misuse due to unreasonable expectations that our
scripts can't live up to.

> With your proposed approach, the user may
> need to manually resolve merge conflicts and so on.  Not all Guix users
> will have the skills or motivation to do this.

*We*, not the users, should get to prepare the cleaned-up repo and fix
the conflicts, if we wish them to bisect for us.

> Even _I_ would not want to do this, because it would mean doing
> unnecessary labor.

It would be unnecessary if we had magic scripts that worked reliably no
matter what you threw at them.  This is not the case, and your
expectation that it is makes you perceive that as unnecessary labor.

That we do only part of that labor, checking only actual releases rather
than all intervening commits, might have been enough of a hint that it
takes actual labor to get what you expect to get with zero effort.

> I would much rather have my computer do this job
> while I do something else, even if it takes longer.

It can do much of it, but not all of it as you expect.  You're
unfortunately objecting to the manual labor in the very cases in which
your computer is unable to do it :-/

-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer