On 24-03-2024 06:35, Elliott Mitchell wrote:
On Sat, Mar 23, 2024 at 10:02:39PM +0100, Olliver Schinagl wrote:
On 23-03-2024 18:51, Elliott Mitchell wrote:
On Sat, Mar 23, 2024 at 03:15:44AM +0100, Olliver Schinagl wrote:
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 :)
Uh huh. If we were playing horseshoes with thermonuclear handgrenades,
that response would get 0 points. You completely missed the point.
Let me add another advantage of doing everything at once. The generated
commits do not properly rebase. Rebasing retains much of the advantage,
but degrades things.
But we neve rebase master? So this would only affect the local changes
for the developer? I do admit 'rebasing the local tree to get the latest
status' is something needed for sure ... I'll check what happens if I do
that as I'm curious how and what breaks.
As such doing all the duplication in one event allows someone who can
directly commit do the task for everyone *once* per update cycle
(presently once per year). Device maintainers can then base off of that
point and not worry about having non-rebasable commits.
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!).
I will not fully type up my viewpoint. Bisecting inherently involves
heuristics. There may be an even number of changes between any two
points, so bisecting involves arbitrarily choosing from a set. The
`git bisect skip` command exists because it *cannot* be perfect.
Meanwhile --find-copies-harder is sufficiently slow to call `git blame`
effectively broken on OpenWRT. It is too slow to be used for most of its
intended use cases.
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 haven't tested, but isn't that simply abandoning the approach of
having history on everything and resorting to only having history on the
up to date version?
I did think that was a viable approach, but it isn't what seemed to gain
concensus.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
