Purpose of openwrt-devel?

[Elliott Mitchell]

On Thu, Mar 14, 2024 at 11:35:15PM +0100, Olliver Schinagl wrote:
> On 14-03-2024 01:50, Elliott Mitchell wrote:
> > On Wed, Mar 13, 2024 at 09:43:06AM +0100, Olliver Schinagl wrote:
> >>
> >> The actual code of course has nothing to do with the perl script, as you
> >> right full say 'I know nothing of perl', as does probably most of the
> >> development community by now. Which is sad for perl, but 'it is what it is'.
> >>
> >> In no way was there any ill intent. I just wanted my kernel tree bump
> >> for the realtek target, and didn't want to install, learn etc perl to
> >> try things out. Sorry for that on my part.
> > 
> > The real problem here is you made two critical errors in your handling
> > of this.
> 
> But we're only talking textual strings, English language. Maybe I came 
> up with nearly similar sounding things because a) English is not my 
> native language and b) I've seen this before 'somewhere on the internet. 
> So re-using your 'code' is a bit of a stretch. Or are you suggesting I 
> am plagarizing everybody with these words I am writing right here? They 
> where all used too. ChatGPT could have been used. Your code in itself, I 
> didn't use, or look at really.

The fact that the same goof appeared in both is strongly suggestive it
was copied, rather than being manually typed in.  True, could be were
both thinking `git rebase` when it was typed, but it is very suspicious.

Those messages aren't that large of a portion of the script.  Whereas
the harm done by getting the script in quickly is quite large.

> > The biggest difference between the two isn't the language choice, but
> > the overall designs.  Your shell script is essentially replicating the
> > actions a human at a shell might take to perform the task (more or less
> > precisely the actions suggested by the original source).  As such you
> > likely recognize all the commands used in the script.
> 
> And that is exactly the point. Human's have to read the script, humans 
> have to understand the script. Readability (in this case, more on this 
> later) is the biggest and most crucial part, as readability (by humans) 
> goes nearly hand-in-hand with maintainability.

Whereas due to better design, mine will likely last rather longer before
needing maintenance.

> > The real reason everyone was having a hard time understanding my script
> > was not that it was written in Perl.

> Yes it was :p perl syntax is godawful :) and adds a layer of complexity 
> around, what in the end are, shell commands. And that's the partial also 
> a problem in my opinion. Many people do not know perl, readability 
> becomes an issue, and thus also maintainability. Yes, someone can argue 
> the same for shell scripts and its tricky syntax hacks. Though I pride 
> myself (and thank shellcheck a lot) for attempting to write as readabile 
> scripts as possible.

Perl heavily copies features and capabilities from shell scripting, but
Perl itself is not a shell-scripting language.  If you're thinking of it
as shell-scripting then, yes it will be confusing.  Further it really
does have some major quirks.  At least it didn't fundamentally change
the language and library between v2 and v3...

> > Since `git fast-import` is a direct interface to Git's back-end, the
> > working tree doesn't need to be modified to operate.  This also means
> > mine is *much* faster and can create precisely tailored commits.

> Ah, but! ... here I go drudging about maintainabiility again. Others in 
> the future will also look at it and go like 'hmm, what is this for, and 
> why the complexity' ...

Anyone needing to figure out how the scripts work will need a fair bit
of familiarity with Git.  Being able to get good results really does need
some deep familiarity with Git's structures, at which point
`git fast-import` isn't a big step further.

> > I had been estimating the shell script would be 2-4 orders of
> > magnitude slower than my Perl script.  I now see the flaw in this belief.
> > I had been operating on the assumption the shell script was doing a
> > roughly comparable job to the Perl script.  Turns out the shell script
> > *strictly* targets the kernel configuration files.  Whereas the Perl
> > script targets *all* kernel-related files.
> 
> If I/we took an oversight, due share. But the script looks at any file 
> (or directory) that has the kernel version suffix. If you look at the 
> realtek tree, you'll config files, but also all the other usual suspects 
> and also some hidden in some subdirectories. So what 'all' files are you 
> referring too that are not part of this pattern and where overlooked?

No, it does not.  It looks at "target/linux/<board>/" for anything
matching the kernel version.  It only looks deeper in the tree for
"config-<oldversion>".  While presently nothing besides the configuration
is deeper in the tree, it isn't at all unlikely for such to be added in
the future.

> > The patches don't get nearly as much press as the kernel configuration
> > files, but they actually have more influence than the configuration.  As
> > someone who has in fact found bugs in the OpenWRT kernel patches, they
> > seem just as valid for this treatment as the configuration.

> Are you talking about patches-5.15 etc? The script should be covering 
> that, I tested it as such. Can you share how/what bug you found?

See above.  You catch "target/linux/<board>/patches-<oldversion>".  It
will miss "target/linux/<board>/<device>/patches-<oldversion>".  This
isn't yet used, but seems entirely likely in the future (or something
else "*-<oldversion>").


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