Skip to contentSkip to conversation

Separate mailing list (and git and patchwork) for fsverity?

DISCUSSION Eric Biggers 2 participants 4 messages Dec 13, 2022 – Jan 4, 2023

Subsystems (3)
lore
Share & tools
lore

Eric Biggers

author maintainer
#0 lore raw

Currently, fsverity development is reusing the same mailing list, git repo (though a different branch), and patchwork project as fscrypt --- mainly just because I was a little lazy and didn't bother to ask for new ones:

FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
[...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fscrypt/list/
T:      git git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git

[...]

FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION [...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fscrypt/list/
T:      git git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git fsverity

[...]

I think this is causing some confusion. It also makes it so that people can't subscribe to the list for just one or the other.

What would people say about having a separate mailing list, git repo, and patchwork project for fsverity? So the fsverity entry would look like:

FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION [...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fsverity/list/
T:      git git://git.kernel.org/pub/scm/fs/fsverity/fsverity.git

[...]

For the branches in the git repo, I'm thinking of using 'for-next' and 'for-current'. (I'd also update the fscrypt ones to match; currently they are 'master' and 'for-stable'.)

If people are okay with these changes, I'll send off the needed requests to helpdesk and linux-next to make these changes, and send Linus a pull request to update MAINTAINERS. (And update fsverity-utils to point to the new list.)

- Eric

author maintainer
#1 lore raw
Quoted 31 lines · Eric Biggers

Currently, fsverity development is reusing the same mailing list, git repo (though a different branch), and patchwork project as fscrypt --- mainly just because I was a little lazy and didn't bother to ask for new ones:

FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
[...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fscrypt/list/
T:      git git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git

[...]

FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION [...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fscrypt/list/
T:      git git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git fsverity

[...]

I think this is causing some confusion. It also makes it so that people can't subscribe to the list for just one or the other.

What would people say about having a separate mailing list, git repo, and patchwork project for fsverity? So the fsverity entry would look like:

FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION [...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fsverity/list/
T:      git git://git.kernel.org/pub/scm/fs/fsverity/fsverity.git

[...]

Quoted 8 lines

For the branches in the git repo, I'm thinking of using 'for-next' and 'for-current'. (I'd also update the fscrypt ones to match; currently they are 'master' and 'for-stable'.)

If people are okay with these changes, I'll send off the needed requests to helpdesk and linux-next to make these changes, and send Linus a pull request to update MAINTAINERS. (And update fsverity-utils to point to the new list.)

Any thoughts on this from anyone?

- Eric

maintainer
#2 lore raw
Quoted 9 lines · Eric Biggers
Quoted 9 lines

What would people say about having a separate mailing list, git repo, and patchwork project for fsverity? So the fsverity entry would look like:

FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION [...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fsverity/list/
T:      git git://git.kernel.org/pub/scm/fs/fsverity/fsverity.git

[...]

This makes sense to me. I wonder if we should use the new
https://lists.linux.dev mailing list hosting service with a mailing list name [email protected]?

The thinking was that we would eventually migrate lists from vger to the new list infrastructure, so it might make sense to just use it for a new list. All mailing lists lists.linux.dev are archived on lore.kernel.org, so other than the e-mail address and using something a bit more modern than Majordomo for list management, it's mostly the same.

- Ted

author maintainer
#3 lore raw
Quoted 15 lines · Theodore Ts'o
Quoted 9 lines · Eric Biggers
Quoted 9 lines

What would people say about having a separate mailing list, git repo, and patchwork project for fsverity? So the fsverity entry would look like:

FSVERITY: READ-ONLY FILE-BASED AUTHENTICITY PROTECTION [...]

L:      [email protected]
Q:      https://patchwork.kernel.org/project/linux-fsverity/list/
T:      git git://git.kernel.org/pub/scm/fs/fsverity/fsverity.git

[...]

This makes sense to me. I wonder if we should use the new
https://lists.linux.dev mailing list hosting service with a mailing list name [email protected]?

Quoted 8 lines

The thinking was that we would eventually migrate lists from vger to the new list infrastructure, so it might make sense to just use it for a new list. All mailing lists lists.linux.dev are archived on lore.kernel.org, so other than the e-mail address and using something a bit more modern than Majordomo for list management, it's mostly the same.

- Ted

Thanks Ted! I'm half-tempted to still use [email protected], for consistency with most of the existing lists... But it does seem that the ship on new lists using lists.linux.dev has already sailed. So I think I'll go with [email protected].

Any other opinions from anyone on this, or on the proposed new git repo and branches, before I send off the helpdesk request?

- Eric