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

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

[jerinj]

From: Jerin Jacob <jerinj@marvell.com>

Based on TB meeting[1] action item, defining
the process for new library approval in principle.

[1]
https://mails.dpdk.org/archives/dev/2023-January/260035.html

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
 content/process/_index.md | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 content/process/_index.md

diff --git a/content/process/_index.md b/content/process/_index.md
new file mode 100644
index 0000000..21c2642
--- /dev/null
+++ b/content/process/_index.md
@@ -0,0 +1,33 @@
++++
+title = "Process"
+weight = "9"
++++
+
+## Process for new library approval in principle
+
+### Rational
+
+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.
+
+### 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.
+
+   - Purpose of the library.
+   - Scope of the library.
+   - Any licensing constraints.
+   - Justification for adding to DPDK.
+   - Any other implementations of the same functionality in other libs/products and how this version differs.
+   - Public API specification header file as RFC
+       - Optional and good to have.
+       - 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.
+
+3. Based on mailing list and TB meeting discussions, TB to vote for approval-in-principle and share
+the decision in the mailing list.
+
-- 
2.39.1

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

[Jerin Jacob]

On Mon, Feb 13, 2023 at 2:56 PM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> Based on TB meeting[1] action item, defining
> the process for new library approval in principle.
>
> [1]
> https://mails.dpdk.org/archives/dev/2023-January/260035.html


Ping for review.


>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
>  content/process/_index.md | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>  create mode 100644 content/process/_index.md
>
> diff --git a/content/process/_index.md b/content/process/_index.md
> new file mode 100644
> index 0000000..21c2642
> --- /dev/null
> +++ b/content/process/_index.md
> @@ -0,0 +1,33 @@
> ++++
> +title = "Process"
> +weight = "9"
> ++++
> +
> +## Process for new library approval in principle
> +
> +### Rational
> +
> +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.
> +
> +### 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.
> +
> +   - Purpose of the library.
> +   - Scope of the library.
> +   - Any licensing constraints.
> +   - Justification for adding to DPDK.
> +   - Any other implementations of the same functionality in other libs/products and how this version differs.
> +   - Public API specification header file as RFC
> +       - Optional and good to have.
> +       - 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.
> +
> +3. Based on mailing list and TB meeting discussions, TB to vote for approval-in-principle and share
> +the decision in the mailing list.
> +
> --
> 2.39.1
>

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

[Thomas Monjalon]

Thanks for formalizing our process.

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"?

> @@ -0,0 +1,33 @@
> ++++
> +title = "Process"
> +weight = "9"
> ++++
> +
> +## Process for new library approval in principle
> +
> +### Rational

s/Rational/Rationale/

> +
> +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.

> +
> +### 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".

TB should be explained: Technical Board.

> +
> +   - Purpose of the library.
> +   - Scope of the library.

Not sure I understand the difference between Purpose and Scope.

> +   - 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

> +   - Public API specification header file as RFC
> +       - Optional and good to have.

You mean providing API is optional at this stage?

> +       - 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?

> +
> +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.

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

[Jerin Jacob]

On Fri, Mar 3, 2023 at 11:55 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Thanks for formalizing our process.

Thanks for the review.

>
> 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.


>
>

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

[Jerin Jacob]

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.
>
>
> >
> >

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

[Jerin Jacob]

On Thu, Mar 30, 2023 at 6:18 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> 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

@Thomas Monjalon  Could you check the below comments and share your
opinion to make forward progress.

>
> >
> > >
> > > 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.
> >
> >
> > >
> > >

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

[Thomas Monjalon]

17/04/2023 15:33, Jerin Jacob:
> 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:
> @Thomas Monjalon  Could you check the below comments and share your
> opinion to make forward progress.
> 
> > > 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

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

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

[Konstantin Ananyev]

> rom: Jerin Jacob <jerinj at marvell.com>
> 
> Based on TB meeting[1] action item, defining
> the process for new library approval in principle.
> 
> [1]
> https://mails.dpdk.org/archives/dev/2023-January/260035.html
> 
> Signed-off-by: Jerin Jacob <jerinj at marvell.com>
> ---
>  content/process/_index.md | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>  create mode 100644 content/process/_index.md
> 
> diff --git a/content/process/_index.md b/content/process/_index.md
> new file mode 100644
> index 0000000..21c2642
> --- /dev/null
> +++ b/content/process/_index.md
> @@ -0,0 +1,33 @@
> ++++
> +title = "Process"
> +weight = "9"
> ++++
> +
> +## Process for new library approval in principle
> +
> +### Rational
> +
> +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.
> +
> +### 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.
> +
> +   - Purpose of the library.
> +   - Scope of the library.

I'd probably extend it to:
Scope and expected usage models of the library.
Apart from that - LGTM.
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>

> +   - Any licensing constraints.
> +   - Justification for adding to DPDK.
> +   - Any other implementations of the same functionality in other libs/products and how this version differs.
> +   - Public API specification header file as RFC
> +       - Optional and good to have.
> +       - 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.
> +
> +3. Based on mailing list and TB meeting discussions, TB to vote for approval-in-principle and share
> +the decision in the mailing list.
> +
> -- 
> 2.39.1

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

[Kevin Traynor]

On 13/02/2023 09:26, jerinj@marvell.com wrote:
> From: Jerin Jacob <jerinj@marvell.com>
> 
> Based on TB meeting[1] action item, defining
> the process for new library approval in principle.
> 
> [1]
> https://mails.dpdk.org/archives/dev/2023-January/260035.html
> 
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
>   content/process/_index.md | 33 +++++++++++++++++++++++++++++++++
>   1 file changed, 33 insertions(+)
>   create mode 100644 content/process/_index.md
> 
> diff --git a/content/process/_index.md b/content/process/_index.md
> new file mode 100644
> index 0000000..21c2642
> --- /dev/null
> +++ b/content/process/_index.md
> @@ -0,0 +1,33 @@
> ++++
> +title = "Process"
> +weight = "9"
> ++++
> +
> +## Process for new library approval in principle
> +
> +### Rational
> +
> +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.
> +
> +### 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.
> +
> +   - Purpose of the library.
> +   - Scope of the library.
> +   - Any licensing constraints.
> +   - Justification for adding to DPDK.
> +   - Any other implementations of the same functionality in other libs/products and how this version differs.

- Dependencies

(Need to know if it's introducing new dependencies to the project)

> +   - Public API specification header file as RFC
> +       - Optional and good to have.
> +       - 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.
> +
> +3. Based on mailing list and TB meeting discussions, TB to vote for approval-in-principle and share
> +the decision in the mailing list.
> +

How about having three outcomes:
- Approval in principal
- Not approved
- Further information needed

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

[Jerin Jacob]

On Wed, Apr 19, 2023 at 9:10 PM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 13/02/2023 09:26, jerinj@marvell.com wrote:
> > From: Jerin Jacob <jerinj@marvell.com>
> >
> > Based on TB meeting[1] action item, defining
> > the process for new library approval in principle.
> >
> > [1]
> > https://mails.dpdk.org/archives/dev/2023-January/260035.html
> >
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> > ---
> >   content/process/_index.md | 33 +++++++++++++++++++++++++++++++++
> >   1 file changed, 33 insertions(+)
> >   create mode 100644 content/process/_index.md
> >
> > diff --git a/content/process/_index.md b/content/process/_index.md
> > new file mode 100644
> > index 0000000..21c2642
> > --- /dev/null
> > +++ b/content/process/_index.md
> > @@ -0,0 +1,33 @@
> > ++++
> > +title = "Process"
> > +weight = "9"
> > ++++
> > +
> > +## Process for new library approval in principle
> > +
> > +### Rational
> > +
> > +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.
> > +
> > +### 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.
> > +
> > +   - Purpose of the library.
> > +   - Scope of the library.
> > +   - Any licensing constraints.
> > +   - Justification for adding to DPDK.
> > +   - Any other implementations of the same functionality in other libs/products and how this version differs.
>
> - Dependencies
>
> (Need to know if it's introducing new dependencies to the project)

Ack. I will add in next version.


>
> > +   - Public API specification header file as RFC
> > +       - Optional and good to have.
> > +       - 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.
> > +
> > +3. Based on mailing list and TB meeting discussions, TB to vote for approval-in-principle and share
> > +the decision in the mailing list.
> > +
>
> How about having three outcomes:
> - Approval in principal
> - Not approved
> - Further information needed

Ack. I will add in next version.

>

[dpdk-dev] [PATCH v1] doc: process for new library approval in principle

[jerinj]

From: Jerin Jacob <jerinj@marvell.com>

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 <jerinj@marvell.com>
---
RFC..v1:
- Fix the review comments by Konstantin, Keven, Thomas at
http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jerinj@marvell.com/

 doc/guides/contributing/index.rst       |  1 +
 doc/guides/contributing/new_library.rst | 48 +++++++++++++++++++++++++
 2 files changed, 49 insertions(+)
 create mode 100644 doc/guides/contributing/new_library.rst

diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 7a9e6b368e..ef627329f1 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -18,3 +18,4 @@ Contributor's Guidelines
     vulnerability
     stable
     cheatsheet
+    new_library
diff --git a/doc/guides/contributing/new_library.rst b/doc/guides/contributing/new_library.rst
new file mode 100644
index 0000000000..7dde8cbe64
--- /dev/null
+++ b/doc/guides/contributing/new_library.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+   Copyright(c) 2023 Marvell.
+
+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.
-- 
2.40.1

Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle

[Jerin Jacob]

On Thu, May 18, 2023 at 6:52 PM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> 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 <jerinj@marvell.com>
> ---
> RFC..v1:
> - Fix the review comments by Konstantin, Keven, Thomas at
> http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jerinj@marvell.com/

Ping for review.

>
>  doc/guides/contributing/index.rst       |  1 +
>  doc/guides/contributing/new_library.rst | 48 +++++++++++++++++++++++++
>  2 files changed, 49 insertions(+)
>  create mode 100644 doc/guides/contributing/new_library.rst
>
> diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
> index 7a9e6b368e..ef627329f1 100644
> --- a/doc/guides/contributing/index.rst
> +++ b/doc/guides/contributing/index.rst
> @@ -18,3 +18,4 @@ Contributor's Guidelines
>      vulnerability
>      stable
>      cheatsheet
> +    new_library
> diff --git a/doc/guides/contributing/new_library.rst b/doc/guides/contributing/new_library.rst
> new file mode 100644
> index 0000000000..7dde8cbe64
> --- /dev/null
> +++ b/doc/guides/contributing/new_library.rst
> @@ -0,0 +1,48 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +   Copyright(c) 2023 Marvell.
> +
> +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.
> --
> 2.40.1
>

Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle

[Jerin Jacob]

On Thu, May 18, 2023 at 6:52 PM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> 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 <jerinj@marvell.com>
> ---
> RFC..v1:
> - Fix the review comments by Konstantin, Keven, Thomas at
> http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jerinj@marvell.com/


Ping for review or merge

Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle

[Ferruh Yigit]

On 5/18/2023 2:21 PM, jerinj@marvell.com wrote:
> From: Jerin Jacob <jerinj@marvell.com>
> 
> 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 <jerinj@marvell.com>
> ---
> RFC..v1:
> - Fix the review comments by Konstantin, Keven, Thomas at
> http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jerinj@marvell.com/
> 
>  doc/guides/contributing/index.rst       |  1 +
>  doc/guides/contributing/new_library.rst | 48 +++++++++++++++++++++++++
>  2 files changed, 49 insertions(+)
>  create mode 100644 doc/guides/contributing/new_library.rst
> 
> diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
> index 7a9e6b368e..ef627329f1 100644
> --- a/doc/guides/contributing/index.rst
> +++ b/doc/guides/contributing/index.rst
> @@ -18,3 +18,4 @@ Contributor's Guidelines
>      vulnerability
>      stable
>      cheatsheet
> +    new_library
> diff --git a/doc/guides/contributing/new_library.rst b/doc/guides/contributing/new_library.rst
> new file mode 100644
> index 0000000000..7dde8cbe64
> --- /dev/null
> +++ b/doc/guides/contributing/new_library.rst
> @@ -0,0 +1,48 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +   Copyright(c) 2023 Marvell.
> +
> +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.yigit@amd.com>

Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle

[Thomas Monjalon]

> > 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 <jerinj@marvell.com>
> > ---
> > RFC..v1:
> > - Fix the review comments by Konstantin, Keven, Thomas at
> > http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jerinj@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.yigit@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).