DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Jerin Jacob <jerinj@marvell.com>,
	web@dpdk.org, dev@dpdk.org, techboard@dpdk.org
Subject: Re: [dpdk-web] [RFC PATCH] process: new library approval in principle
Date: Tue, 25 Apr 2023 00:31:43 +0200	[thread overview]
Message-ID: <2995154.687JKscXgg@thomas> (raw)
In-Reply-To: <CALBAE1MTAaRrvr7k5oxrtbkwVne0egLf-BKpbJP7qrLxxmioBg@mail.gmail.com>

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



  reply	other threads:[~2023-04-24 22:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13  9:26 jerinj
2023-03-01  8:28 ` Jerin Jacob
2023-03-03 18:25 ` Thomas Monjalon
2023-03-15 13:47   ` Jerin Jacob
2023-03-30 12:48     ` Jerin Jacob
2023-04-17 13:33       ` Jerin Jacob
2023-04-24 22:31         ` Thomas Monjalon [this message]
2023-04-10 13:42 ` Konstantin Ananyev
2023-04-19 15:40 ` Kevin Traynor
2023-04-20 10:17   ` Jerin Jacob
2023-05-18 13:21 ` [dpdk-dev] [PATCH v1] doc: process for " jerinj
2023-06-06 16:06   ` Jerin Jacob
2023-07-20  6:33   ` Jerin Jacob
2023-07-20  8:03   ` Ferruh Yigit
2023-07-25 10:19     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2995154.687JKscXgg@thomas \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=techboard@dpdk.org \
    --cc=web@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).