Hey Daniel,
On 14-03-2024 02:40, Daniel Golle wrote:
On Wed, Mar 13, 2024 at 05:50:36PM -0700, Elliott Mitchell wrote:
<snip>
Anyway. The true dependency on Github is everything they offer besides
git:
Bug tracker, Pull Requests, comments made on PRs, comments made on
commits, ... scraping all that data is much more tricky should we ever
desire to move that somewhere else.
Indeed. And while I certainly won't intend to dig up the GitLab vs
github discussion, it's been had, it's been done, it's been decided. But
this is what might have been missed in the earlier discussion. "Picking
up and moving elsewhere" is much much harder now. With Gitlab (be it
freedesktop's or whatever), you can export and self-host, keeping
everything as yours.
And, afaik gitlab allows a more seemless mailinglist + gitforge
integration. But the ship is sailed, so lets not dwell on this further
(unless others seriously want to re-consider :p)
Imho for people who don't like following submitted patches as emails
in their inbox there is patchwork.
I think patchwork is an atroctity to work with, but that's comming from
someone who doesn't use it much and doesn't understand it, so I'm
certainly biased.
Having everything in two places -- Github and patchwork -- certainly
isn't perfect and I'd also rather want to see all that in a single
one-size-fits-them-all interface like sourcehut. However, I also got
neither resources nor experience in hosting such as service in the
scale we would need.
Afaik gitlab does have mailing list integration-ish support. But again,
it was decided, and until we re-evaluate, it is what it is.
And those are my 2 ;)
Olliver
Just my 2 cents.
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.
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.
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.
In light of this, I think the qualities of the two scripts and their
merits should be considered.
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.
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.
The real reason everyone was having a hard time understanding my script
was not that it was written in Perl. 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.
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.
(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)
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.
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.
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!)
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sig...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
