Messages in this thread | | | From | Thorsten Leemhuis <> | Subject | Re: [RFC PATCH v2 00/26] Make reporting-bugs easier to grasp and yet more detailed & helpful | Date | Thu, 19 Nov 2020 13:29:51 +0100 |
| |
Am 19.11.20 um 01:29 schrieb Jonathan Corbet: > On Sun, 15 Nov 2020 11:13:52 +0100 > Thorsten Leemhuis <linux@leemhuis.info> wrote: > >>> So I've not had a chance to try to read through the whole thing again, >>> will try to do so in the near future. >> Great, thx, looking forward to it. > OK, I have made a *quick* pass through the whole thing and sent a small > number of comments separately.
Great, thx, much appreciated.
> There are things that could be tweaked > (there always will be) but I'm not sure we should worry about those yet. > I would suggest doing this: > > - Collapse the whole thing down to a patch adding reporting-bugs-v2.rst > (or some suitable name).
Maybe just "reporting-issues.rst" or "reporting-issues-wip.rst". The text talks about issues anyway and rarely uses the word "bug".
> I do wonder if it should also move to the > process manual as part of this; not only admins will report bugs.
I had wondered about this myself a few weeks ago, but I assumed someone had good reasons to put it in the admin section.
/me looks closer
Hmmm, now I'm unsure myself where to place it:
* Documentation/admin/ is introduced as "The Linux kernel user’s and administrator’s guide" (https://www.kernel.org/doc/html/latest/admin-guide/). So maybe it's the right place that just uses a directory name that's easily misunderstood :-/
* the process section starts with the words "So you want to be a Linux kernel developer? Welcome!" (https://www.kernel.org/doc/html/latest/process/). That might be a bit intimidating for people that just want to report a bug.
I guess it's best if you decide.
> - Add a comment at the top saying it's a proposed replacement and > soliciting comments. You could also put some of your other questions > into the text for now and see if anybody reacts. > > - In a separate patch you could add a comment to the existing document > pointing to the new one as the true source of wisdom.
Will do.
> - Dual licensed CC-SA-4.0 is fine with me. CC-BY is OK if you really > want to do it that way.
I'm unsure and would appreciate options from others here.
Here are some of my thoughts about this:
What do we loose by dual-licensing it under a liberal license like CC-BY? It afaics makes it a lot more attractive for websites or books authors to use this text as a base, as they don't need to fear that "share alike" or the GPL might have consequences on the surroundings. I'd say that's a good thing for the kernel, as it increases the chances the texts built upon ours remain close to what we expect on this topic.
That's why I currently think using CC-BY is a good idea.
> Either way, though, you'll need to add the > license itself under LICENSES/preferred before it can go into the SPDX > tag.
Agh, yes, of course, will keep it in mind when above point is settled.
Ciao, Thorsten
| |