On Tue, Jan 14, 2025 at 07:29:14PM +0100, Brendan Jackman wrote:
> > Tweaks aimed at checkpatch are only useful during the code review stage, so
> > once that code is accepted upstream, they become wholly irrelevant. A
> > checkpatch trailer in the permanent commit record serves no purpose, not
>
On Tue, Jan 14, 2025 at 03:25:41PM +0100, Brendan Jackman wrote:
> wrote:
> > Do we really want this to become part of the permanent commit message? I'm
> > pretty sure this won't go over well with many.
>
> Why not?
Tweaks aimed at checkpatch are only useful during the code review stage, so
onc
On Mon, Jan 13, 2025 at 04:04:22PM +, Brendan Jackman wrote:
> Checkpatch sometimes has false positives. This makes it less useful for
> automatic usage: tools like b4 [0] can run checkpatch on all of your
> patches and give you a quick overview. When iterating on a branch, it's
> tiresome to m
On Wed, Nov 13, 2024 at 04:25:57PM -0700, Shuah Khan wrote:
> +The scope of the ban for a period of time could include:
> +
> +a. denying patch contributions and pull requests
> +b. pausing collaboration with the violator by ignoring their
> + contributions and/or blocking their email
the
> > communication that is the focus of this policy, not general access like git,
> > patchwork, etc.
> >
>
> Thank you Konstantin. Correct. The intent is to restrict communication.
> The way you phrased it makes perfect sense. I will make the change.
Thank you!
Acked-by: Konstantin Ryabitsev
-K
ners
> see.
I consider the prep/send parts a bit experimental still, as they do
periodically explode. :) However, we will find and fix more corner cases as
the user base grow(l)s, so I'm all for this inclusion.
Acked-by: Konstantin Ryabitsev
-K
On Thu, Jun 27, 2024 at 05:51:47AM GMT, Thorsten Leemhuis wrote:
> I thought it was documented, but either I was wrong or can't find it.
> But I found process/5.Posting.rst, which provides this example:
>
> Link: https://example.com/somewhere.html optional-other-stuff
>
> So no "# " ther
On Wed, Jun 26, 2024 at 10:12:35AM GMT, Geert Uytterhoeven wrote:
> > > + Link: https://patch.msgid.link/patch-source-msgid@here
> >
> > Hmm, I mentioned this in the other thread, but I also like the fact
> > that my automated script uses the list that it was Cc'd to. That is, if
> > it Cc'd li
On Fri, Jun 21, 2024 at 02:07:44PM GMT, Kees Cook wrote:
> On Wed, Jun 19, 2024 at 02:24:07PM -0400, Konstantin Ryabitsev wrote:
> > + This URL should be used when referring to relevant mailing list
> > + topics, related patch sets, or other notable discussion threads.
> >
domains
Cc: ksum...@lists.linux.dev
Link:
https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat #
[1]
Signed-off-by: Konstantin Ryabitsev
---
Documentation/process/maintainer-tip.rst | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff
less likely to overload our systems.
Acked-by: Dan Williams
Signed-off-by: Konstantin Ryabitsev
---
Documentation/process/2.Process.rst | 8
Documentation/process/howto.rst | 10 +-
Documentation/process/kernel-docs.rst| 5 ++---
Documentation/pr
es are the result of discussions on the ksummit
mailing list [2].
Link: https://subspace.kernel.org # [1]
Link:
https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat/
# [2]
Signed-off-by: Konstantin Ryabitsev
---
Changes in v2:
- Minor wording changes to text and commi
On Wed, Jun 19, 2024 at 10:12:51AM GMT, Leon Romanovsky wrote:
> Default b4.linkmask points to https://msgid.link/ and not to
> https://patch.msgid.link/
That's the default for the b4 project itself, though, not the global default.
> https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/.b4-config
There have been some changes to the way mailing lists are hosted at
kernel.org, so fix the links that are pointing at the outdated
resources.
Signed-off-by: Konstantin Ryabitsev
---
Documentation/process/2.Process.rst | 8
Documentation/process/howto.rst | 10
domains
Cc: ksum...@lists.linux.dev
Link:
https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat #
[1]
Signed-off-by: Konstantin Ryabitsev
---
Documentation/process/maintainer-tip.rst | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git
es are the result of discussions on the ksummit
mailing list [2].
Link: https://subspace.kernel.org # [1]
Link:
https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat/
# [2]
Signed-off-by: Konstantin Ryabitsev
---
Konstantin Ryabitsev (2):
Documentation: fix links
On Tue, Apr 23, 2024 at 08:00:16PM +0300, Jani Nikula wrote:
> Imagine the commit message Cc was named "Attn:" and handled
> appropriately. That probably reflects a lot of commit message Cc
> usage.
This is especially the case for get_maintainer.pl purposes. Adding a Cc:
in a commit message mean
The mailman2 server running on lists.linuxfoundation.org will be shut
down in very imminent future. Update all instances of obsolete list
addresses throughout the tree with their new destinations.
Signed-off-by: Konstantin Ryabitsev
---
Jon, I am sending this primarily to linux-doc, since most
be https://kernel.org/releases.html
Reviewed-by: Konstantin Ryabitsev
-K
On Wed, Nov 15, 2023 at 07:56:32PM +0200, Laurent Pinchart wrote:
> When the base of a series is in Linus' tree, or in the corresponding
> subsystem maintainer's tree, things are easy, but there are many
> situations where the base is a merge of multiple branches (perhaps a
> for-next and a fixes b
On Wed, Jun 26, 2019 at 08:25:41AM -0600, Jonathan Corbet wrote:
On Wed, 26 Jun 2019 17:11:46 +0300
Jarkko Sakkinen wrote:
I was getting myself a smartcard stick and looked for options from [1].
The documentation says that Nitrokey Pro does not support ECC while it
actually does [2]. I was alr
Newer devices like Yubikey 5 and Nitrokey Pro 2 have added support for
NISTP's implementation of ECC cryptography, so update the guide
accordingly and add a note on when to use nistp256 and when to use
ed25519 for generating S keys.
Signed-off-by: Konstantin Ryabitsev
---
.../process/maint
On Thu, Feb 01, 2018 at 11:14:50AM -0700, Jonathan Corbet wrote:
- Capitalizing "Kernel" bugs me. Obviously not a big deal.
Noted.
- The "master keys vs. subkeys" section is nice, but it's missing one
thing, IMO: a sentence saying what a subkey *is* in the first place.
I'll work that in
On Wed, Jan 31, 2018 at 09:18:11AM +0200, Jani Nikula wrote:
Just one nit, I think it would be better to move the Maintainer: bit
from the end near the top as a reStructuredText field list. See 'git
grep :Author:' under Documentation for examples. Could even add a
MAINTAINERS entry to improve you
even those who do rarely remember that such wiki
exists. Keeping it with the rest of in-kernel docs should hopefully give
it more visibility, but also help keep it up-to-date as tools and
processes evolve.
Signed-off-by: Konstantin Ryabitsev
---
Documentation/process/index.rst
even those who do rarely remember that such wiki
exists. Keeping it with the rest of in-kernel docs should hopefully give
it more visibility, but also help keep it up-to-date as tools and
processes evolve.
Signed-off-by: Konstantin Ryabitsev
---
Documentation/process/index.rst
On 11 January 2018 at 08:36, Konstantin Ryabitsev
wrote:
> Let me do this -- I'll go ahead and produce the document I think would be
> good for kernel devs, based on the more generic document I mentioned
> earlier. Then I will get in touch again so we can see if that version is
&g
could use some love, but I think the latter is nice enough to
> warrant a link from the main page.
You're right, it's an oversight that is now fixed, see www.kernel.org.
Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
--
To unsubscribe f
On Wed, Jan 10, 2018 at 02:05:16PM -0700, Jonathan Corbet wrote:
Does such document belong with the rest of the kernel docs in the
tree,
or should it remain fully external? I'll be happy to port it to RST if
you think it should live alongside other documents like coding
standards.
My immediate
Hi, all:
I would like to adapt this document to be more specific to kernel
development:
https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
This stems from many back-and-forth conversations with kernel devs, and
I believe many would benefit from such guide, especially sin
This is probably the lamest patch ever, but then again "Welcome to The
Linux Kernel's documentation" is nearly equally lame. Really, we don't
need to "Welcome" people to the documentation, just tell them what the
site is about.
Signed-off-by: Konstantin Ryabitsev
-
Hello:
I had someone ask me today whether
https://www.kernel.org/doc/html/latest/ is covered by GNU GPL or GNU
FDL, and honestly I wasn't sure, as there is actually no clear
indication. There's places where FDL is listed
(https://www.kernel.org/doc/html/latest/media/uapi/fdl-appendix.html),
e "htmldocs" at [3] are decreasing.
This is now fixed -- please behold:
https://www.kernel.org/doc/html/latest/
Regards,
--
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec
--
To unsubscribe from this list: send the line "unsubs
33 matches
Mail list logo
