Purpose of openwrt-devel?

[Olliver Schinagl]

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.
> 
>