Messages in this thread | | | From | Miguel Ojeda <> | Date | Mon, 22 Jun 2020 01:43:12 +0200 | Subject | Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/process |
| |
Hi Alexander,
On Sun, Jun 21, 2020 at 4:30 PM Alexander A. Klimov <grandmaster@al2klimov.de> wrote: > > Which discussion? 93431e0607e5 ? IMAO the patches don't depend on each > other.
The one we had the other day. It does not matter that the patches depend on each other. It is information for whoever sees this commit.
> IMAO: > > * The script should not be neccessary once all of my changes[1] arrive > in torvalds/master. Instead reviewers should say like C'mon dude, what's > this new plain-HTTP link doing in your patch? We have 2020! Look at e.g. > 93431e0607e5 .
In an ideal world, yes, but that won't happen unless enforced somehow.
Nevertheless, even in such a case, it would be best to have a script to check the entire tree from time to time.
> * The program language agnostic algo description of mine should be > enough. If it's not enough, I shall improve the description.
Then you are asking the next person to re-do the work.
> * Today I've added "If not .svg:". Imagine Torvalds merges the script, > closes the merge window *and then* someone runs it on a random subsystem > and discovers a missing condition. Do they have to patch the script, > wait for the patch to arrive in torvalds/master *and then* patch the > (other) subsystem, so they can refer to the now patched script? W/o a > such central "rule on how to HTTPSify links" they'd just describe > *their* algo. Or (even better) there wouldn't be much more insecure > links, so the algo could be omitted.
I don't follow. They can patch the script if they want (or not), but even if they do patch it, they don't need to wait for the patch to land.
> After all please show me one of the big bosses (Torvalds, K-H, ...) > who'd tolerate to have a... > > * written w/o focus on maintainability > * not documented at all > * *Golang* file > > ... in the kernel tree.
It is a script, not part of the kernel building process. We already have Perl, Python, C++, Makefile, Coccinelle...
But yes, it would be better to write it in a language that we already have rather than add another. In particular, there is no need for a compiled language for a script.
> If I correctly understand, you kernel devs write code so that if even > the maintainer leaves the project, another one could just take over. > > How many kernel devs would read and understand (all of them I guess) > *and maintain that Go script* of mine?
What is the problem reading and maintaining a Go script (notwithstanding the point above)?
Cheers, Miguel
| |