Messages in this thread | | | Subject | Re: [PATCH 0/6] Address issues with SPDX requirements and PEP-263 | From | Markus Heiser <> | Date | Sat, 7 Sep 2019 16:36:36 +0200 |
| |
Am 07.09.19 um 15:34 schrieb Jonathan Corbet: > On Thu, 5 Sep 2019 16:57:47 -0300 > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > >> The description at Documentation/process/license-rules.rst is very strict >> with regards to the position where the SPDX tags should be. >> >> In the past several developers and maintainers interpreted it on a >> more permissive way, placing the SPDX header between lines 1 to 15, >> with are the ones which the scripts/spdxcheck.py script verifies. >> >> However, recently, devs are becoming more strict about such >> requirement and want it to strictly follow the rule, with states that >> the SPDX rule should be at the first line ever on most files, and >> at the second line for scripts. >> >> Well, for Python script, such requirement causes violation to PEP-263, >> making regressions on scripts that contain encoding lines, as PEP-263 >> also states about the same. >> >> This series addresses it. > > So I really don't want to be overly difficult here, but I would like to > approach this from yet another angle... > >> Patches 1 to 3 fix some Python scripts that violates PEP-263; > > I just checked all of those scripts, and they are all just plain ASCII. > So it really doesn't matter whether the environment defaults to UTF-8 or > ASCII here. So, in other words, we really shouldn't need to define the > encoding at all. >
Thats what I mean [1] .. lets patch the description in the license-rules.rst::
- first line for the OS (shebang) - second line for environment (python-encoding, editor-mode, ...) - third and more lines for application (SPDX use) ..
[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg33240.html
-- Markus --
> This suggests to me that we're adding a bunch of complications that we > don't necessarily need. What am I missing here? > > Educate me properly and I'll not try to stand in the way of all this... > > Thanks, > > jon >
| |