Hello Thorsten, Am Thu, Feb 24, 2022 at 09:19:24AM +0100 schrieb Thorsten Leemhuis: > On 24.02.22 01:14, Kees Cook wrote: > > +If you are a first time contributor it is recommended that the patch > > +itself be vetted by others privately before being posted to public lists. > > +(This is required if you have been explicitly told your patches need > > +more careful internal review.) These people are expected to have their > > +"Reviewed-by" tag included in the resulting patch. Finding another > > +developer familiar with Linux contribution, especially within your own > > +organization, and having them help with reviews before sending them to > > +the public mailing lists tends to significantly improve the quality of the > > +resulting patches, and there by reduces the burden on other developers. > > I like the section, but I wonder why it's needed here. Is there anything > specific to patches produced from research in it there I missed when > reading it? If not: Wouldn't it be better to include that section as a > TLDR in Documentation/process/submitting-patches.rst and point there > instead? We already have at least two places describing how to submit > patches, creating yet another one (even if it's just in such a brief > version) somehow feels slightly wrong to me. > > OTOH I fully understand that having things in one place has it's > benefits. If that's wanted, why not put that text as TLDR in > submitting-patches.rst and maintain a copy here? Sure, keeping things in > sync has downsides, but I'd say it's the lesser evil. A copy could also > be avoided by briefly mentioning some of the important bits found in > another document; that's the approach I took in my patches regarding > regressions. To quote: Without further opinion on the topic or content itself: If there's need to have "copied" parts of the documentation available in different places, why not put that to a separate file and include it in all places which need it? This would solve the manual synchronization issue. Did that in other projects using sphinx/rst already. Only thing you have to keep an eye on is whether the surrounding context at places of the include still matches the included piece. Greets Alex
