Purpose of openwrt-devel?

[Olliver Schinagl]

Hey Elliott,

On 14-03-2024 01:50, Elliott Mitchell wrote:
> On Wed, Mar 13, 2024 at 09:43:06AM +0100, Olliver Schinagl wrote:
>> On 13-03-2024 08:46, Felix Baumann wrote:
>>> Am 13. März 2024 05:11:23 MEZ schrieb Elliott Mitchell<ehem+openwrt at m5p.com>:
>>>> I must challenge this.  If patches via the mailing list were accepted,
>>>> then we should see things sent to the mailing list getting into the
>>>> repository.  Yet many patches get no attention.  Some get reviews from
>>>> various people, yet then never get into the main repository.
>>> It's the same for Github, some stuff doesn't get in and remains there. There might be a difference what kind of PRs are send to the mailing list and you get attention of different committers when sending to mailing list vs sending to Github. Github patches might be accepted more easily when it's just a new device for a well established target.
>>>
>>> I feel like patches on the mailing list are ignored, when committers don't have time for review or don't feel confident enough to do it well (not their field of expertise). Or if it's written in a language they don't feel confident reviewing.
>>
>> *PERSONALLY* I think mailing list reviews are on their way out. People
>> have found that there are easier and better ways. Granted, some folks
>> still _prefer_ mailing list reviews. *I PERSONALLY* do not at all. I
>> hate my mailbox being full with threads of stuff I have no attention for
>> at that moment, it just adds noise for me. And ignoring it for a  while
>> just puts huge amounts of e-mails in my mailbox, that become useless
>> after a while. Though I much rather would like to see GitLab then GitHub
>> use :p but that's more the FOSS spirit, and avoiding anything Microsoft
>> where possible :p
> 
> Mailing list reviews do have their moments.  Notably I thought some
> parts might deserve wider discussion.  Also by sending it here I was
> trying to engage with the person who originally found the solution.
> 
> I am another person who is concerned about GitHub.  The degree of
> copyright infringement by AI isn't known to be large, but there are hints
> of trouble on the horizon.  Good news is Git is very much P2P and moving
> things between Git servers is easy.

But as Daniel pointed out, that's just the code, everything else 
valueable, you "loose". Issues, reviews, CI etc etc. But see my reply to 
Daniel for more agreement.

> 
> 
>>> Huh.  Parts of that look suspicious.  Those commit messages look *very*
>>> similar to my version 2.  I was jumping between documentation sources
>>> when writing it.
> 
>> Not sure what is surprising to you, since the mail thread was listed in
>> the MR and your perl code was even referenced (not _directly_ I admit).
>> Obviously I was using your messaging format as that was discussed on the
>> mailing list and I didn't want to deviate from those messages, also they
>> made a lot of sense anyway. "Fair Use" if anything :p
> 
> A Court of Law would need to decide Fair Use, but I'm pretty sure this
> would fail.  Good news is this isn't enough to bother.
> 
>> 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.

> 
> First, credit the original author for everything.  Open source depends
> heavily on reputation so letting people know doing this as a script was
> my idea has high value to me.  I take the above as an apology, so there
> there is little to do, besides drop this portion.

Thank you! Though to be fair, the mailing list posted, with the 'manual 
git way of doing it' was used :p

> 
> Second, I knew nothing of https://github.com/openwrt/openwrt/pull/14713
> until yesterday and Robert Marko mentioning something, triggering me to
> go searching:
> https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042423.html
> Had I known of the pull earlier I would have gone to #14713, but I had no
> idea the discussion had been diverted away to GitHub.

I suppose that is one of the issues being discussed already, two 
distinct review tracks.

> 
> In light of this, I think the qualities of the two scripts and their
> merits should be considered.

Sure thing, as I wrote on github; we can always interate and improve on 
a v2.
> 
> 
> One item I was trying to draw attention to was perhaps the current
> approach to handling kernel version changes isn't very good.  If you're
> trying to change configuration which effects multiple devices, you end up
> having to *constantly* watch out for configuration files appearing and
> disappearing.  This is painful to deal with.
> 
> This has the useful advantage of producing fewer merge commits.  Instead
> of 44 merges/kernel version, there would be only 1.  I estimate OpenWRT
> is doing around 3000 commits/year, so this is 1.5% versus 0.03% commit
> merges.  If a typical bisect session touches 12 commits then this is
> 16.5% versus 0.45% encountering a merge.  Then there are sessions which
> encounter 2+ merges.
> 
> 
> 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.

> 
> My Perl script uses a very different approach.  Pretty much all of Git's
> interface is designed to be readily parseable and useful for scripting.
> Some portions are really meant /only/ for script use and not meant for
> interactive use.

Yep, the plumbing commands, the 'porcelain' commands.

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

>  The real reason everyone was having
> a hard time with the script is relatively few people are ever exposed to
> `git fast-import`.  Since 75% of the script is interacting with
> `git fast-import` you'll be lost without having at least passing
> familiarity.

Er, I didn't even notice that part, but if I did, I would have looked at 
the man page, and scratched behind my ear 'what does this do, and why is 
it usefull' :)

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

> 
> (if someone wishes to learn about `git fast-import`, I suggest starting
> by playing with `git fast-export`, you may want to use "--no-data" to
> omit noise you don't want to play with)

Usefull thank you!

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

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

> 
> Due to invoking Git for every single operation it does, the shell script
> needs to invoke Git roughly 80 times for its present operation.  If it
> was modified to be on-par with the Perl script, it would invoke Git
> about 110 times.  This would be massively slower since it needs to modify
> the working tree to do its job.
> 
> Meanwhile the Perl script invokes Git 5 times and never touches the
> working tree, nor interacts with anything besides Git.
> 
> 
> So, my belief is my Perl script provides better functionality and is
> much faster while doing so.  (yes, as the author of course my stuff is
> better!)

Of course it is :) And I appreciate that, but my fear, is that this is 
'premature optimization evil' biting you. Who cares if the perl version 
is 100 times faster? Who cares if it takes 5 minutes to run (assuming it 
works and it works 'just fine'). The script gets used once or twice per 
year for each target. Yes, that's probably 2 hours of execution time all 
combined. But who cares? Now if we where running this every other day, 
you'd have a good point (and even then, do we need this performance).

At the end of the day, *I personally* value readability and 
maintainability far more then execution time, especially in this case.


Anyway, in the end, I had no means of offending you whatsoever, nor did 
I think I 'stole' anything from you. My reasons where simple. This idea 
was lingering in my head ever since when I saw the hackernews post on 
keeping git 'copy' (the blog post referenced in the mailing list). When 
the mailing list post came up, I was happy others where sharing the same 
thoughts.

With love,

Olliver