On 18-03-2024 01:34, Elliott Mitchell wrote:
On Sun, Mar 17, 2024 at 11:44:45AM +0100, p...@oranjevos.nl wrote:
Op 16 mrt. 2024, om 07:46 heeft Elliott Mitchell <ehem+open...@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.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
