Purpose of openwrt-devel?

[Olliver Schinagl]

On 18-03-2024 01:34, Elliott Mitchell wrote:
> On Sun, Mar 17, 2024 at 11:44:45AM +0100, por at oranjevos.nl wrote:
>> Op 16 mrt. 2024, om 07:46 heeft Elliott Mitchell <ehem+openwrt at m5p.com> het volgende geschreven:
>>> On Sat, Mar 16, 2024 at 02:19:27PM +0800, Chuanhong Guo wrote:
>>>> And more comments on the perl thing:
>>>> A maintainer needs to be familiar with perl to review or take your
>>>> patches. I could probably vaguely understand what a perl script
>>>> is doing by quickly learning the syntax, but I can't decide
>>>> whether the script is good or not.
>>>> Nobody is explicitly NACKing your patch or saying it's worse
>>>> than the bash version just because it's written in perl. Maintainers
>>>> who don't understand perl simply don't have the knowledge to
>>>> judge the script, so the patch is left for others. If such a maintainer
>>>> doesn't show up, your patch won't be taken. It doesn't matter if
>>>> your script is superior or not.
>>> That makes forward progress impossible.  If it provides superior results
>>> then perhaps the thing which only one person understands is acceptable?
>>> As long as they maintain it, provide reasonable explanations and help
>>> others work on gaining proper understanding, isn't that good enough?
>> Ever considered to implement the kernel bumps based on 'git fast-import' in sh script in stead of perl ?
> Well...
>
> The choice of Perl+fast-import was guided by my aims.  I wanted to do as
> little as possible as possible to the working tree in order to reduce
> problems from someone trying the script in a dirty tree.  For POSIX shell
> this simply isn't so advantageous.  Unfortunately you've caused me to
> wonder about it a bit, so...
>
> First thoughts.  Should be possible.  This isn't nearly so fast or robust
> since fast-import is a *binary* protocol, *not* a text protocol.  In
> particular it uses line-feeds, *not* newlines (subtle, but critical
> difference).
>
> Second thought.  Pretty difficult.  Perl was simple due to being able to
> open a pipe and leave it around stuck to a variable.  Shell isn't really
> well-suited to this.
>
> Third thought.  Above I was thinking of an approach similar to what I did
> with Perl.  If instead a more traditional fast-import fixed stream
> approach was used, this is actually suitable for shell operation.
>
> So, yes indeed shell+fast-import is quite doable.  I'm unsure of it being
> particularly advantageous.  This would need a *bunch* of temporary files
> to hold intermediate work before merging everything together.
>
> My goal though was to do the job well, not to show off fast-import.
>
>
I expect this to be done very rarely and by users that know what they 
are doing, but just "automating" a few logical git commands.

Performance is not a key-driver here. It's too rarely used.

Users that do not know what they are doing? Are they the ones doing 
kernel bumps?

I will add a little warning/error when the kernel tree is a non-clean 
state, and prevent the script from running. But going back (or trying to 
fix a failure) should still b e preferred, to avoid starting the process 
when it's already known it can't continue.

Leaving the tree in failed state imo is a feature. We switch from the 
normal branch to a special branch to do all operations. The user can 
always force ably switch back. Ultimately, this is a choice, can a user 
fix things and inspect failures, or 'oh it failed, lets reset'. Reset 
instructions during cleanup is a good idea however.