Hi all As part of a process of aligning a couple of branches based on old etherlabmaster versions, I have taken the Gavin Lambert patchset 20190904 and rebased it to current stable-1.5.
There are several changes made on the old default branch, and in the patchset that the products rely on, so for now, we cannot simply use stable-1.5 as-is. As the 20190904 patchset is based on a specific commit (hg revision 33b922) from the (now deprecated/unsupported) default branch, I rebased the patchset in 3 steps. 1. Rebase of the 33b922 revision to the new stable-1.5 branch as of 20141028 (git commit c02e204fcb5b). Pushed to branch hg-default-33b922-rebased-to-stable-1.5-20141028 2. Rebase of the branch created in step 1 to latest stable-1.5 commit (git commit 1fa5565aa028). Pushed to branch hg-default-33b922-rebased-to-stable-1.5-20210609 3. Applied the 20190904 patchset (minus stable/*.patch), trying to resolve any conflicts found. Pushed to gavin-patchset-20190904-stable-1.5-20210609 All of the branches above are for all practical purposes only meant for inspiration/review. They are not in any to be considered upstream, and no merge requests or anything like that will be considered. Also, the rebased branches have only been very lightly tested as of now. Work on that will be started ASAP. The question is then. What, if anything, can and should we do with all this? I believe it will be in everybodys interest to get back to a situation where we have a common baseline to work on, or maybe a small number of aligned common baselines. What is acceptable for getting merged to stable-1.5 branch? I assume that any backwards compatible bugfixes is fine. But what about changes that modifies the ioctl() API/ABI? And what about changes that modifies the user-space library API and/or ABI? If there are changes which cannot be merged to stable-1.5, can we create a new branch (something like development-1.6?) to have a common place to share this work? And if we do this, we need to agree on to keep that branch aligned with stable-1.5, so we don't end up with another "default" branch to be abandoned a few years up the road. Best regards, Esben -- Etherlab-dev mailing list Etherlab-dev@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-dev
