Hello, Mark, On Aug 25, 2020, Mark H Weaver <m...@netris.org> wrote:
> Alexandre Oliva <lxol...@fsfla.org> wrote: >> On Aug 15, 2020, Mark H Weaver <m...@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
