Purpose of openwrt-devel?

[Elliott Mitchell]

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.

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.


-- 
(\___(\___(\______          --=> 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