Purpose of openwrt-devel?

[Olliver Schinagl]

On 23-03-2024 18:51, Elliott Mitchell wrote:
> On Sat, Mar 23, 2024 at 03:15:44AM +0100, Olliver Schinagl wrote:
> 
> True enough.  Though I will cite this as an example of the care used in
> the design.

I can't argue the design, not because I can't read it; but because I'm 
sure you've put a lot of care and attention into it, hence your pation 
for it :)

> 
> 
>>> 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?!
> 
> Taking the unusual step of splitting a paragraph since that is needed
> in this case.
> 
> I've cited two specific reasons in a recent message.  I keep citing those
> reasons again and again and again.  Yet get no response.
> 
> This makes it *much* easier to change defaults in "generic".  Instead of
> needing to touch a bunch of configurations with different versions, you
> can simply touch all configurations with one version.  If you're unlucky
> and a new kernel cycle starts before approval or rejection, you can
> rebase one copy onto the rename commit and another onto the merge commit.
> You then rebase these on top of each other and then squash, the result is
> you're onto the latest with minimal trouble.  Without this trying to
> modify values effecting multiple devices is an absolute nightmare
> (believe me, I know!).

Hmm, afaik this is what openwrt does right now, the generic config is 
applied to all targets, and you put your device specific configuration 
in your platform config. This makes sense, because you don't want to 
compile all drivers for all targets into your tiny router image, that is 
restricted to 4MiB.

So if there's something I'm missing, I do appologize :)

> 
> Without a doubt copying the configurations and patches is only a single
> trivial step.  Yet unless you're aware of a board/device which doesn't
> copy configurations and patches as an early step, this is no reason not
> to do them all at once.
> 
> For that matter, if it is such a small step why bother with a script?

Ah, yes, well the initial idea was 'lets put it on the wiki' but then I 
can assure you, noone will do it (unless maintainers are super ademant.

Then there's the debugging 'you did it wrong, please do it right'.

It's again, all about the human factor here. Telling some one 'just run 
this script, done' makes it less error prone and easier to do. Nothing 
more, nothing less. I think the goal is for it to _be_ super simple.

> 
> 
>> 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.
>>
> 
> Yet all this leaves me concerned about assumptions being made.  I've
> already pointed to one example (it assumes you're on a local branch).
> 
> While the name is not the sort most humans would use, it is still
> creating and deleting a branch when it doesn't need to.  I've got an odd
> suspicion it will start to require more features of your development
> environment.

But why would you not do this as a human? That's what the original 
instructions where, so that's what humans would do, right?

Checkout a branch, do the work, merge it back. So you found a better 
way, which is amendable. However it's too hard to grok for _most_ humans :p

But for what it's worth, I've put up the question on the ML whether it 
would be usefull to have `git cp` and solve it in a far nicer way :) 
Doubt we'll see it before the end of the year :)

> 
> 
>>>>> 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?
> 
>>> 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 ...
> 
> You're not the only person who doesn't devote 100% time to OpenWRT.
> Theory was the better capabilities would become clear with a bit of
> experimentation.
> 
>>> 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?
> 
> You've been typing about how yours could upgrade everything by being
> called multiple times.  Since I was aiming to get the above issue
> discussed `scripts/kernel_upgrade.pl` has featured the capability to
> update everything all at once, from the start.

The kitchen sink :) But honestly, have that discussion first with the 
maintainers. Hauke is already much against it; which I get. Having 
worked on a few targets, they are so diverse, bumping two at once just 
doesn't make sense (today!).

> 
> In fact only upgrading a single board was a feature which had to be
> added.  Since I added fewer assumptions, mine makes no distinction
> between upgrading targets versus subtargets.  It can do multiple of both
> at the same time without any restrictions and a single invocation.
> 
> In the process, only 2 commits are generated.  The under .5s is for
> updating *everything*.

I have no idea how long it would take to update everything, but again, 
the time factor is so irrelevant, it doesn't atter. Also, I too only 
have 2 commits now, which until we get `git cp` will remain the minimum, 
but more then a 'cp && git add'.

> 
> I'm ending up with an odd suspicion the extra experiment is the way to
> go.  Some developers might consider `kernel_bump.sh`'s UI better, yet
> `kernel_upgrade.pl` has a rather better back-end.
> 

But is it important :)