Re: [dpdk-web] [RFC PATCH] process: new library approval in principle

[Jerin Jacob <jerinjacobk@gmail.com>]

On Wed, Mar 15, 2023 at 7:17 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Fri, Mar 3, 2023 at 11:55 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > Thanks for formalizing our process.
>
> Thanks for the review.

Ping

>
> >
> > 13/02/2023 10:26, jerinj@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.
>
>
> >
> >