On Wed, Mar 15, 2023 at 7:17 PM Jerin Jacob <jerinjac...@gmail.com> wrote: > > On Fri, Mar 3, 2023 at 11:55 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > > > Thanks for formalizing our process. > > Thanks for the review.
Ping > > > > > 13/02/2023 10:26, jer...@marvell.com: > > > --- /dev/null > > > +++ b/content/process/_index.md > > > > First question: is the website the best place for this process? > > > > Inside the code guides, we have a contributing section, > > but I'm not sure it is a good fit for the decision process. > > > > In the website, you are creating a new page "process". > > Is it what we want? > > What about making it a sub-page of "Technical Board"? > > Since it is a process, I thought of keeping "process" page. > No specific opinion on where to add it. > If not other objections, Then I can add at > doc/guides/contributing/new_library_policy.rst in DPDK repo. > Let me know if you think better name or better place to keep the file > > > > > > @@ -0,0 +1,33 @@ > > > ++++ > > > +title = "Process" > > > +weight = "9" > > > ++++ > > > + > > > +## Process for new library approval in principle > > > + > > > +### Rational > > > > s/Rational/Rationale/ > > Ack > > > > > > + > > > +Adding a new library to DPDK codebase with proper RFC and then full > > > patch-sets is > > > +significant work and getting early approval-in-principle that a library > > > help DPDK contributors > > > +avoid wasted effort if it is not suitable for various reasons. > > > > That's a long sentence we could split. > > OK Changing as: > > Adding a new library to DPDK codebase with proper RFC and full > patch-sets is significant work. > > Getting early approval-in-principle that a library can help DPDK > contributors avoid wasted effort > if it is not suitable for various reasons > > > > > > > + > > > +### Process > > > + > > > +1. 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 TB approval-in-principle. > > > > I think we can remove "code base". > > Ack > > > > > TB should be explained: Technical Board. > > Ack > > > > > > + > > > + - Purpose of the library. > > > + - Scope of the library. > > > > Not sure I understand the difference between Purpose and Scope. > > Purpose → The need for the library > Scope → I meant the work scope associated with it. > > I will change "Scope of the library" to, > > - 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. > > > > > > + - Any licensing constraints. > > > + - Justification for adding to DPDK. > > > + - Any other implementations of the same functionality in other > > > libs/products and how this version differs. > > > > libs/products -> libraries/projects > > Ack > > > > > > + - Public API specification header file as RFC > > > + - Optional and good to have. > > > > You mean providing API is optional at this stage? > > Yes. I think, TB can request if more clarity is needed as mentioned below. > "TB may additionally request this collateral if needed to get more > clarity on scope and purpose" > > > > > > + - TB may additionally request this collateral if needed to get > > > more clarity on scope and purpose. > > > + > > > +2. TB to schedule discussion on this in upcoming TB meeting along with > > > author. Based on the TB > > > +schedule and/or author availability, TB may need maximum three TB > > > meeting slots. > > > > Better to translate the delay into weeks: 5 weeks? > > Ack > > > > > > + > > > +3. Based on mailing list and TB meeting discussions, TB to vote for > > > approval-in-principle and share > > > +the decision in the mailing list. > > > > I think we should say here that it is safe to start working > > on the implementation after this step, > > but the patches will need to match usual quality criterias > > to be effectively accepted. > > OK. > > I will add the following, > > 4. Once TB approves the library in principle, it is safe to start > working on its implementation. > However, the patches will need to meet the usual quality criteria in > order to be effectively accepted. > > > > > >
