From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 45D8CA0A02; Tue, 18 May 2021 14:26:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B24334068E; Tue, 18 May 2021 14:26:00 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 894E640041 for ; Tue, 18 May 2021 14:25:59 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EDEFA5C01EB; Tue, 18 May 2021 08:25:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 18 May 2021 08:25:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= XamSk0Qoy4QM7U2miBeh3G2GZA1dANvP3EzwZySNTPo=; b=xJGpy++v6UrJvWJP iPEsOtBPBD0NRDIJ1MGwyM8PAP4YECYkUQqYac9nfJvWSwr2DXOOgQl8wYrcmmWe dQe1z5BVU01wx5WM8NsEbNn8tSH9kK4aN3MCOajxnWkRAAC/6MAc1gHzT8Q/LsAF 7SHMEPyEULYfrTtY7JNZ5Mgb9iaSEtTPR9mULanmkz4vpU/fQdM7J5/ji0bcRK57 xrutJapMAn8btHd7t1Y+8s63sffzUa4+UHQ4XTkScvQXRasJ5Pg8f3fqI8vd8oNe Uos2K2Rj3VRZ5lvsiO4z7hDaz/ycPwlU/OPBJmpq28fxgq7jIaVzy6UiuHlIzMz6 oNr1YA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XamSk0Qoy4QM7U2miBeh3G2GZA1dANvP3EzwZySNT Po=; b=aLLhu1H7dmpruaQ9ZBDbzaKtgq+UjhJq/WHKLrYBN4zOO2nWP4A3lvg2F v6JBYDg3v2pfv3h+UKkIJWRMVslMdQ6GhSq0McHvISX4jLtb6NwS1F1oYary4mfA Mlvqs2h20oEnDem3FJV6KxqnvzVPU+shBc0MjWATD9e1WRTWBIy9cuf6W9hw8si5 jsJf9Iv398ZQAhUKiSxiUEn9PEAW6eNNNdffXxTTZx8CVAD8qXNrYJ9MmoGpQBsv D4aurypDWIDAiifZuUshCqH2OI15DvbBm1CledwMU5or8NzOmlvdRieGX5ajvF7c lUXk6nVF67phoEq+hrpo+gSvFfjWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeijedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 May 2021 08:25:57 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, david.marchand@redhat.com, Asaf Penso , John McNamara Date: Tue, 18 May 2021 14:25:56 +0200 Message-ID: <5731405.XtSjWBXQUY@thomas> In-Reply-To: <45ecbd36-089c-a8a6-740f-3660310dee9d@intel.com> References: <1610304247-11455-1-git-send-email-asafp@nvidia.com> <20210328190005.4185594-1-thomas@monjalon.net> <45ecbd36-089c-a8a6-740f-3660310dee9d@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 18/05/2021 13:57, Ferruh Yigit: > On 3/28/2021 8:00 PM, Thomas Monjalon wrote: > > From: Asaf Penso > > > > Adding more information about the release milestones. > > This includes the scope of change, expectations, etc. [...] > > +rc1 > > +~~~ > > + > > +* Priority: new or updated API. > > Can we just say API or libraries? Yes > Overall what is the intention for the 'priority' information? Should we really > split release candidates for libraries, driver and applications? > We merge all as much as possible before -rc1. The idea is to simply reflect the priority in case time is limited. But yes we always merge as much as possible. > Can we say this other-way around, API/library features can't be merged after -rc1. Correct > And similarly driver features shouldn't be merged after -rc2, application > changes shouldn't merge after -rc3. > Fixes can be merged anytime before -rc4. After -rc4 only critical fixes and > documentation changes. > > Just I want to highlight that for example we merge documentation updates > anytime, it doesn't have to wait -rc4, but below listing looks like different > part only allocated for different -rc, which is wrong as far as I know. I understand the confusion and will try to make it clearer in next revision. > > +* New API should be defined and implemented in libraries. > > +* The API should include Doxygen documentation > > s/should/must OK > > + and be part of the relevant .rst files (library-specific and release notes). > > +* API should be used in a test application (``/app``). > > +* At least one PMD should implement the API. > > + It can be a draft but must be sent as a separate series. > > I am not sure if "must be sent as a separate series" needs to be highlighted, > having all in the same series has a benefit to see bigger picture. If the driver > patches acked/reviewed by its maintainers, I think it can be merged in single > series. That's not the same kind of review for driver and API, not the same time constraint, and not the same iterations. I think it is more practical to suggest separate, but it should not be "must". > > +* The above should be sent to the mailing list at least 2 weeks before -rc1. > > +* Nice to have: example code (``/examples``) > > + > > +rc2 > > +~~~ > > + > > +* Priority: drivers. > > +* New features should be implemented in drivers. > > I already mentioned above, but this can cause misunderstanding. We want all > driver implementation to be ready for proposal deadline, same as other patches. > But because of its reduced scope (they don't affect all project but only > specific vendor), we are flexible to get driver features for -rc2 and -rc3 too. -rc3 really? It should be exceptional so not mentioned here. > Please check number of driver patches merged for a release, it is impossible to > manage them within period between -rc1 & -rc2. > Also some driver features are complex and big, they should be sent before > proposal deadline so that they can be reviewed for the release. Yes sooner is better. The doc is about deadline + priorities, showing the no-go limits, without warranty of merge if all good. Is there a contradiction? > > +* A driver change should include documentation > > s/should/must Sometimes there is no doc to change. Is "must" confusing? > > + in the relevant .rst files (driver-specific and release notes). > > +* The above should be sent to the mailing list at least 2 weeks before -rc2. > > + > > +rc3 > > +~~~ > > + > > +* Priority: applications. > > +* New functionality that does not depend on libraries update > > + can be integrated as part of -rc3. > > Again for same issue, let me share my understanding, > the -rc1 has been tested widely, after that each -rc gets less and less tests. > So the -rc1 should have API/library changes, so that they will be tested more > and will have more time to fix any issues, since library changes has biggest > impact for the project. > > Next biggest impact is drivers. > > Applications and unit tests are internal to DPDK, they have no user impact, that > is why we can get more risk with them and they can be merged even as late as rc3. > > And documentation doesn't have anything related to testing, or they don't > introduce any risk for specific release, so they are merged until last stage of > the release. Yes > > +* The application should include documentation in the relevant .rst files > > + (application-specific and release notes if significant). > > s/should/must > > > +* It may be the last opportunity for miscellaneous changes. > > This is very vague, what does misch changes mean? Scripts, code cleanup, yes it is vague, we can remove. > > +* Libraries and drivers cleanup are allowed. > > +* Small driver reworks. > > +* Critical and minor bug fixes. > > + > > +rc4 > > +~~~ > > + > > +* Documentation updates. > > +* Critical bug fixes.