Purpose of openwrt-devel?

[Elliott Mitchell]

On Wed, Mar 13, 2024 at 01:55:07AM +0100, Robert Marko wrote:
> On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell <ehem+openwrt at 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+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445