Purpose of openwrt-devel?

[Olliver Schinagl]

Heyb Elliot,

On March 21, 2024 10:28:29 p.m. GMT+01:00, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
>On Thu, Mar 21, 2024 at 10:00:46AM +0100, Olliver Schinagl wrote:
>> On 20-03-2024 01:34, Elliott Mitchell wrote:
>> > On Mon, Mar 18, 2024 at 10:53:12AM +0100, Olliver Schinagl wrote:
>> >> I expect this to be done very rarely and by users that know what they
>> >> are doing, but just "automating" a few logical git commands.
>> >>
>> >> Performance is not a key-driver here. It's too rarely used.
>> > True, though being faster is nice.
>> 
>> While true, I don't think we even have to start arguing if runtime is 
>> less then a single second. This on my 12 year old PC, granted, the CPU 
>> is only 8 years and the nvme SSD only 5.
>> 
>> ./scripts/kernel_bump.sh -p realtek -s 5.15 -t 6.6  0,40s user 0,33s 
>> system 105% cpu 0,694 total
>> 
>> ./scripts/kernel_bump.sh -p ramips -s 6.1 -t 6.6  0,40s user 0,40s 
>> system 106% cpu 0,753 total
>> 
>> Even if you bumped all repo's (with a dumb for-loop) we'd be talking 30 
>> seconds to do _all_ of them at once (which never happens).
>
>On a computer of similar class, but with *much* slower storage
>(fileserver is sick and underperforming): real    0m0.477s
>
>So if this was directly to an SSD, 2 orders of magnitude.

Sure, but not significant in any way or form. Its still in both cases significantly less then one second. The script has executed before my finger has left the enter key. There is no purpose or advantage here. If the script ran 10 seconds, it wouldn't even matter IMO.

>
>
>Odd thing about what you put in parentheses.  I've been trying to get a
>discussion going about that for months, yet seems no one notices the
>suggestion.  This was a distinct goal of the script, to hopefully get
>that discussion going.

To update all targets at once? How is that useful?! If a target is fully upstream, there is nearly nothing to migrate, no patches etc. So maybe the kernel config. Sure expanding (either script) to accept multiple platforms would be trivial or accept a commit pair per platform andere just loop over the script fort each target. But this is something not feasible for decades to come.

Bumping a kernel version pretty much always requires additional work. Config migration, rebasing patches, testing on actual hardware. Its just not even worth considering.

Also, a quick note on skipping kernel versions, generally openwrt seems to only support two versions at a time. You could have just a single one, or skip 5. The problem/work, is adapting the target to actually function again. Bigger jumps just means different/more work on the patches, but nothing else really.

>
>
>> >> Leaving the tree in failed state imo is a feature. We switch from the
>> >> normal branch to a special branch to do all operations. The user can
>> >> always force ably switch back. Ultimately, this is a choice, can a user
>> >> fix things and inspect failures, or 'oh it failed, lets reset'. Reset
>> >> instructions during cleanup is a good idea however.
>> > Therein lines a concern.  Why does yours switch to a special branch?
>> > It is not human, it doesn't need a computer to keep track of commits for
>> > it.  As such it shouldn't need a branch.
>> 
>> Why is this a problem? Why can't a script that is intended to remove 
>> manual labor, behave like a human. There comes the readability and 
>> maintainability argument once again. If a human can read it, he can 
>> modify it. If the script fails, or a special case pops up, a human can 
>> do those steps manually quite easily.
>> 
>> I'm a big beliver in KISS. So yes, the script is not perfect and doesn't 
>> have shiney gold plated parts. But it is simple, can be understood by a 
>> human, by a non-developer even I'd argue.
>> 
>> In the end, computers do what humans tell them to do. In the end, humans 
>> reading things is far more important, then super-optimizing a script, 
>> that's run once or twice a year by a human developer.
>> 
>> And using a branch does have its advantages too. We can switch to the 
>> branch and examine if things go wrong. Again, this is something a human 
>> would do too :)
>
>A human can tell `git` to move to an unreferenced commit.  Useful to know
>how if things go wrong.  Though I will admit by having your script be so
>close to things many people do, does make it more obvious to more people.
>

Yeo yhats my point, humane neef tot read, write, understand whats ging on, at least in general ways.

>Yet if that is an issue they should be looking at the URL where the
>approach came from and reading that.

That's probably a step too far, this is using magical got internals. But sure. I'd thing someone sees the git mv, git commit, git checkout and figures ohh, i think i get it', but of course to understanf deeper research is still needed. I just disagree with making things (appear to the general reader) very complex, and then expect them to research the theory is to far.

>
>> > If you examine the result, you might also discover its approach has some
>> > rather substantial advantages.  At this time I believe with the second
>> > commit it offers a proper superset of your script's functionality.
>> >
>> I wonder what this super set is though and why it is so badly needed ...
>
>Your knowledge level is showing.

I've had set theory in units yes. But its still not clear which superior features the Perl version offers. How is it massivly better. How is the result majorly different? What is so super (pun intended) in your approach?

>
>Given a Set A and Set B:
>
>Set A is a superset of Set B, if:
>For all elements 'b' of Set B, element 'b' is also an element of Set A.
>
>Set A is a subset of Set B, if:
>For all elements 'a' of Set A, element 'a' is also an element of Set B.
>
>Set A is a degenerate superset of Set B, if:
>Set A is a superset of Set B; and there is NO element 'a' of Set A,
>which is NOT also an element of Set B.  (ie they're the same set)
>
>Set A is a proper superset of Set B, if:
>Set A is a superset of Set B; and there is at least one element 'a' of
>Set A, which is NOT an element of Set B.
>
>
>```
>git remote add ehem https://github.com/ehem/openwrt.git
>git remote set-branches ehem bumper script
>git fetch ehem
>git rebase ehem/bumper ehem/script
>```
>
>The UI approach for `kernel_upgrade.pl` is rather distinct from what
>`kernel_bump.sh` has.  I'm unsure how closely what it does matches the
>behavior of your script.  Yet the modified `kernel_bump.sh` performs
>similar to what you have, by invoking `kernel_upgrade.pl` once with
>appropriate arguments.

I'll test it soon ;) Just got some personal stuff to deal with ...

>
>Then there are the things `kernel_upgrade.pl` can do which
>`kernel_bump.sh` has no equivalent.

But what are they. And how are they relevant?

Olliver
>
>