> > Based on techboard meeting[1] action item, defining the process for a > > new library approval in principle. > > > > [1] > > https://mails.dpdk.org/archives/dev/2023-January/260035.html > > > > Signed-off-by: Jerin Jacob <jer...@marvell.com> > > --- > > RFC..v1: > > - Fix the review comments by Konstantin, Keven, Thomas at > > http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jer...@marvell.com/ [...] > > +Process for new library approval in principle > > +============================================= > > + > > +Rationale > > +--------- > > + > > +Adding a new library to DPDK with proper RFC and then full patch-sets is > > significant work. > > +In order to save effort, developers will get an early approval in > > principle, or early feedback in > > +case the library is not suitable for various reasons. > > + > > +Process > > +------- > > + > > +#. When a contributor would like to add a new library to DPDK code base, > > the contributor must send > > + the following items to DPDK mailing list for technical board > > approval-in-principle. > > + > > + * Purpose of the library. > > + * Scope of work: outline the various additional tasks planned for this > > library, such as > > + developing new test applications, adding new drivers, and updating > > existing applications. > > + * Expected usage models of the library. > > + * Any licensing constraints. > > + * Justification for adding to DPDK. > > + * Any other implementations of the same functionality in other > > libraries/projects and how this > > + version differs. > > + * Public API specification header file as RFC. > > + > > + * Optional and good to have. > > + * Technical board may additionally request this collateral if > > needed to get more clarity > > + on scope and purpose. > > + * Any new library dependencies to DPDK. > > + > > +#. Technical board to schedule discussion on this in upcoming technical > > board meeting along with > > + author. Based on the technical board schedule and/or author > > availability, technical board may > > + need a maximum of **five** technical board meeting slots. > > + > > +#. Based on mailing list and technical board meeting discussions, > > technical board to vote and share > > + the decision in the mailing list. The decision outcome can be any of > > the following. > > + > > + * Approved in principal > > + * Not approved > > + * Further information needed > > + > > +#. Once technical board approves the library in principle, it is safe to > > start working on the > > + implementation. However, the patches will need to meet the usual > > quality criteria in order to be > > + effectively accepted. > > > Looks reasonable to me, and it is good to start to document the process > anyway, we can tweak it later if required, hence: > > Acked-by: Ferruh Yigit <ferruh.yi...@amd.com>
I prefer the new page having a broader scope: adding a new library. So I make this new doc as a chapter of a new page "Adding a new library". Applied, thanks. Later we could add some tips for new libraries: what to copy elsewhere, what to not forget (maintainer, doc, test, doc indexes, etc).
