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 :)
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
