Hello, 05/03/2025 02:33, Aaron Conole: > The DPDK project has two constrained resources - reviewers and > public CI infrastructure. These are shared among the entire > project, and there are true costs associated with using these > resources. Thus, there are two motivations behind this change: > - Encourage developers to spend more time ensuring their > changes are in a state that things have gone through some > basic testing > - Encourage people to give reviews by guaranteeing that the > time between series is long enough that comments will be > valid.
Thanks for trying to improve our process. > We want to document the guidelines for submitting to the list > to encourage more time for reviews, and also encourage > developers to spend a bit more time to put their submissions > in a 'default accept' condition. > > Signed-off-by: Aaron Conole <acon...@redhat.com> > --- > +Frequency and volume of patches > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +Please allow at least 24 hours to pass between posting patch revisions. > +This ensures reviewers from different geographical regions have time to > +provide feedback. > +Additionally, please do not wait too long (read: weeks) between revisions > +as this makes it harder for reviewers and maintainers to recall the context > +of the previous posting. Should we recommend to ping after a week of inactivity? > + > +Please do not post new revisions without addressing all feedback. > +Make sure that all outstanding items have been addressed before posting a new > +revision for review. Should we remind to reply to all feedbacks? > +Do not post a new version of a patch while there is ongoing discussion unless > +a reviewer has specifically requested it. > + > +Do not post your patches to the list in lieu of running tests. > +**YOU MUST ENSURE** that your patches are ready by testing them locally > before Should we be more precise about "testing them locally"? Or recommend minimal testing like 1 compilation target with unit test or DTS? > +posting to the mailing list. > +The infrastructure running the tests is a shared resource among all > developers > +on the project, and many frequent reposts will result in delays for all > +developers. > +We do our best to include CI and self-test infrastructure that can be used on > +an individual developer basis. This self test infra should be explained a bit more. > + > +Your changes are expected to pass on an x86/x86-64 linux system. This can be moved above with "local test" recommendation. > + > +Keep all patch sets to a reasonable length. > +Too many or too large patches and series can quickly become very difficult > +for a reasonable review. To be clear, you recommend to split patches and series appropriately. Thanks again. I would love reading more comments and feedbacks about this.
