drivers/crypto sub-tree maintainer volunteer
Hi all,
I'm just following up on discussions from DPDK user space and the on going discussions regarding the maintenance of development sub-trees etc. I just wanted to re-iterate my offer to maintain a sub-tree for the cryptodev library and all crypto PMDs in drivers/crypto.
Thomas, I will leave it up to you whether you want to wait until the initial patch set has been merged into main and then create the sub-tree, or whether you would like to create the sub-tree now and take the crypto features as a pull request after they have been fully reviewed and acked.
Thanks
Declan
2015-10-21 10:26, Declan Doherty:
Quoted 4 lines
I'm just following up on discussions from DPDK user space and the on going discussions regarding the maintenance of development sub-trees etc. I just wanted to re-iterate my offer to maintain a sub-tree for the cryptodev library and all crypto PMDs in
drivers/crypto.
Thanks Declan
Quoted 5 lines
Thomas, I will leave it up to you whether you want to wait until the initial patch set has been merged into main and then create the sub-tree, or whether you would like to create the sub-tree now and take the crypto features as a pull request after they have been fully reviewed and acked.
We can manage the initial import directly and prepare the crypto tree in the meantime. Please send your SSH key.
Should we create a separate mailing list and patchwork?
Quoted 8 lines · Thomas Monjalon
2015-10-21 10:26, Declan Doherty:
Quoted 4 lines
I'm just following up on discussions from DPDK user space and the on going discussions regarding the maintenance of development sub-trees etc. I just wanted to re-iterate my offer to maintain a sub-tree for the cryptodev library and all crypto PMDs in
drivers/crypto.Thanks Declan
Quoted 8 lines
Quoted 5 lines
Thomas, I will leave it up to you whether you want to wait until the initial patch set has been merged into main and then create the sub-tree, or whether you would like to create the sub-tree now and take the crypto features as a pull request after they have been fully reviewed and acked.
We can manage the initial import directly and prepare the crypto tree in the meantime. Please send your SSH key.
Will do.
Quoted 2 lines
Should we create a separate mailing list and patchwork?
personally I think keeping a single mailing list for the moment is preferable. The mailing lists volume isn't so great yet that we need separate lists, also by creating a list for each sub-tree, is there a danger that we could stratify the discussion, developers would need to keep abreast of work being done in each sub-tree and to keep track of each multiple lists, especially as there will no doubt be patch sets that will go into a sub tree that also contain changes which affect code outside of that tree.
I'm not sure if separate patchwork lists are possible without separate mailing lists but we could work around that by allowing sub-tree committers access to modify the main patchwork list, when the commit patches.
2015-10-21 12:06, Declan Doherty:
Quoted 5 lines · Thomas Monjalon
Quoted 1 line
Should we create a separate mailing list and patchwork?
personally I think keeping a single mailing list for the moment is preferable. The mailing lists volume isn't so great yet
I would say we need to reduce the volume on [email protected].
Quoted 4 lines
that we need
separate lists, also by creating a list for each sub-tree, is there a danger that we could stratify the discussion, developers would need to keep abreast of work being done in each sub-tree
I think a lot of developers don't really care about the internals of the drivers and some care only about drivers. But having too many list archives can be cumbersome. What about enforcing some tags in the mail titles or using some email aliases redirecting to [email protected]? It would allow to filter emails.
Quoted 4 lines
and to keep track of
each multiple lists, especially as there will no doubt be patch sets that will go into a sub tree that also contain changes which affect code outside of that tree.
If a patchset is about crypto, it must be managed in the crypto tree, even if it touches small parts of EAL and obviously doc, config, apps. But the crypto API must be changed with more care. Maybe there could be a double-ack rule.
Quoted 4 lines
I'm not sure if separate patchwork lists are possible without separate mailing lists but we could work around that by allowing sub-tree committers access to modify the main patchwork list, when the commit patches.
It's better to have dedicated patchwork to make review of a specific area easier. By using tags or mail alias, we can redirect to the right patchwork.
Opinions?