17/04/2023 15:33, Jerin Jacob: > 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: > @Thomas Monjalon Could you check the below comments and share your > opinion to make forward progress. > > > > 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
Maybe that the contributing guide is the best place. I'm OK with a new file doc/guides/contributing/new_library.rst which could document more than the policy in future (like things to remember and to check). > > > > +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 It will be easier if starting with the goal: 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. > > > > > > > > + - 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. OK > > > > + - 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" OK > > > > +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. OK
