On Wed, Mar 13, 2024 at 01:55:07AM +0100, Robert Marko wrote: > On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell <ehem+open...@m5p.com> wrote: > > > > Well, what purpose does the openwrt-devel mailing list serve? > > > > As near as I can tell it looks suspiciously like it is a method to divert > > developers from where everything is done. There isn't too much review > > activity. Anything which does get a positive review tends to simply > > disappear unless it is later resubmitted via GitHub. > > > > According to https://openwrt.org/submitting-patches patch submission via > > GitHub or the openwrt-devel mailing list can be done. The amount of text > > seems to suggest the mailing list is preferred. Yet, can anyone cite a > > single patch which was sent to the mailing list, reviewed positively and > > brought into the main branch without resubmitting via GitHub?
> Both methods of submitting changes are accepted. I must challenge this. If patches via the mailing list were accepted, then we should see things sent to the mailing list getting into the repository. Yet many patches get no attention. Some get reviews from various people, yet then never get into the main repository. > > Then there is technical discussion. > > > > A rather serious problem with how kernel version changes are handled was > > brought up. This eventually lead to: > > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html > > Which seemed to gain a consensus of being the best solution to the > > problem. > > > > Due to this not being the easiest process to implement, I went and > > created a script for automating the process: > > https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html > > While some negotiation was expected, nothing has happened. I was > > expecting to need some adjustment to match other's development > > environments, yet no problems have been found. > > > > Yet now, 8a9273d51e simply throws the consensus in the garbage. Why was > > something which there was consensus on ignored? Perhaps this mailing > > list is now >99% ignored and people should no longer be directed here? > > It is not ignored, it was just a case where kernel 6.6 support was already > done > by the time we merged the kernel bump script that does the GIT magic to > preserve the history and with multiple people working on 6.6 target support > based of the same PR it was not practical to stall it any further. > > I expect further kernel bumps, both generic and target ones will use the > script > and preserve history but it will take some time to get everybody > familiar with it. Fascinating. The original technique, which does not require scripting was suggested Tue Oct 24 05:05:25 PDT 2023. Scripting isn't necessary. Scripting is a good idea since it would be done on a regular basis. https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html My second revision was visible Wed Feb 7 13:32:19 PST 2024. This version *needed* some discussion. Parts of what it produces are different from the way things had been previously done. I think this is a major improvement, but it did need discussion (and testing). https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html My third revision was visible Sun Mar 3 15:24:50 PST 2024. It had been ready for *weeks*, but I had been expecting more feedback. https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042405.html Now that I've found what you're refering to: https://github.com/openwrt/openwrt/pull/14713 AuthorDate: 2024-02-23 13:54:48 Huh. Parts of that look suspicious. Those commit messages look *very* similar to my version 2. I was jumping between documentation sources when writing it. Quoting my version: ------8<---------------------------------------------------------8<------ If you see this commit during a `git bisect` session, the recommended course of action is to run `git bisect --skip`. ------8<---------------------------------------------------------8<------ Whereas the "bumper script": ------8<---------------------------------------------------------8<------ During a `git bisect` session, `git bisect --skip` is recommended. ------8<---------------------------------------------------------8<------ Now when writing mine I was thinking of `git rebase --skip`, yet for `git bisect` the command is `git bisect skip`. Odd that precisely the same thinko occured in both. Quite a few other messages look like rewrites of mine too. I'm pretty sure an attorney would advise against filing a lawsuit. There amount which looks copied seems unlikely to get much. On the flip side that looks copied enough that I suspect the OpenWRT organization should have asked for a sign-off by me. Now what Olliver Schinagl meant when typing "unreadable perl code" during #14713 was they didn't know anything about Perl nor did they know how my script functioned. My script used Perl since it can do far more than POSIX shell. While Python isn't as handy for manipulating strings. To do the job my script accomplishes in 1 pass, you would need to invoke Olliver Schinagl's script about 100 times. Olliver Schinagl's likely invokes `git` about 100-300 times for every run, while my script invokes `git` 5 times. As a result mine is likely 2-4 orders of magnitude faster. This is an estimate, but fork()/execvp() are by themselves quite expensive. > > If action is taken quickly, the breakage in 8a9273d51e might be mostly > > fixed. Check out 71360660e6, use the script to do an update and check > > out the result. Then run `git merge --no-commit main` and then run > > `git commit --amend`. I *think* this should generate the correct > > result (squashing two merge commits together, creating a 3-way merge). > > We cannot really change GIT history at this point I am afraid. Indeed. Did someone suggest you change GIT history? What you should have done was: ``` git fetch github refs/pull/14751/head git branch tmp FETCH_HEAD git rebase main tmp git checkout main git merge 71360660e68bbc5bdc9cde89fd66ba5104e59106 ``` Then use an update script. Then do: ``` git rebase main tmp git checkout main git merge --ff-only tmp git push $destination ``` This would have replaced the copy which was part of #14751 with what the script does. Since this option is now closed off, it is still possible to get most of the desireable result. First grab my script (https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042405.html there is no need to bring it into the repository now, we just need a temporary copy due to its capabilities) Now, find the line `$git->putcmd("merge $start");` (line 255). Above this line add `$git->putcmd('merge origin/main');`. Then do: ``` git checkout 71360660e68bbc5bdc9cde89fd66ba5104e59106 ./kernel_upgrade.pl 6.1 6.6 git merge --ff-only $hash_reported_by_script git diff origin/main -- include package target/linux/generic target/linux/mediatek | patch -p1 -R -f git add -- include package target/linux/generic target/linux/mediatek git commit --amend git branch new git checkout main git merge --ff-only new git branch -d new ``` Now, please compare the new result you're looking at (`git diff origin/main main`) to ensure it looks plausible. There *will* be differences since my script has taken care of configuration and patches for *all* devices (or at least all devices which have a 6.1 kernel). Mostly you need to ensure any other device which got updated for kernel 6.6 doesn't lose its updates. The reason is the script was meant to run just after 71360660e6, so it ignores anything which is preexisting. Please also check `git blame -- target/linux/generic/config-6.6` to ensure it originated at fa79baf4a6e. I rest my case on why my script is superior. Note, "origin/main" is meant to be a reference to the OpenWRT HEAD. If you use a different remote name for the primary tree, then adjust to match the remote name you use. I'm also using "main" as a presumed name for your primary local branch, if you use "master" that should be substituted. The "new" branch isn't actually required, if you're up for copying&paste of sha1 values there is no need for the branch. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
