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 7A75AA0C43; Tue, 14 Sep 2021 09:56:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 28A304068F; Tue, 14 Sep 2021 09:56:12 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 5B73E4003C for ; Tue, 14 Sep 2021 09:56:10 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 09F505C00FE; Tue, 14 Sep 2021 03:56:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 14 Sep 2021 03:56:10 -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; s=fm2; bh=4wzXuzWcA0EV+ 3tP/yaZEwuU2ZeObXTXegs/OpY7wKQ=; b=InZaD91SoBasYsroDI4Og4rhNVwBc 47aEVEEeA0wHUCZUG4ZM7bcUsMBk2PJfR7VH/T/ADrqEYsTCMbrL7QsgwOT195kg Z3WW/G5vJaijvLluF0Zh9oP62LGPybucr7+er3Ph8nqxr91EjLrC37K8jNEZXkk9 54sXvKRpQXDN65GtMtuqqTRwQQSEloZdKhgMd2t32lU6RssbGtyIQ1ZhHCzxb+ms jNWw52ByuZvh70oaB6sAkLwcAbM60Y6Pxf+NUvMyV8/MulZ/3053/f4OvB+ghsIo b/M/Ue4IuV0k4WgWZ6tG6UhYrgGQCRCqmd5ys6VuhaVlpnwabQVkca7Eg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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= fm3; bh=4wzXuzWcA0EV+3tP/yaZEwuU2ZeObXTXegs/OpY7wKQ=; b=U0jhHXjm mQe3ra53/YonaWFPea2PJgR2YACljXRyhoIb/SG5V3SyHr2WvXKpsLUhV06TBBv0 bwgYQG1zlGn8KRvk6E4Dx2Gfqd7GwXew5NkrLTkcGuu9d2y1PM6SUniHaGUl0Er5 Zq6frFzFDXDGN957VqTWApV6NAff2IJnRug3xn5lk0+yV6gFfL8KRhz1vT/zliey N5SGGJWq5C6ByVYwfygo4i/kbmtyl9jWUZruDYwOYhmP9WfVxKwBDv9tRevCTpzg ywcpTx4Z1rULvwo7o/pyTu3z5CdHv8I5HMsN4AoPdTG6XiHKm+qYeff5noa6BAaD Hw4MUbLZp6t2AA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegkedguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeehtdduuefggeekveehueeitdefhfdvkeevtedvfeeivdffudeu udehudetiedvudenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Sep 2021 03:56:07 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: david.marchand@redhat.com, ferruh.yigit@intel.com, Asaf Penso , John McNamara , Ajit Khaparde , Bruce Richardson , Andrew Rybchenko Date: Tue, 14 Sep 2021 09:56:04 +0200 Message-Id: <20210914075604.2156324-1-thomas@monjalon.net> X-Mailer: git-send-email 2.33.0 In-Reply-To: <1610304247-11455-1-git-send-email-asafp@nvidia.com> References: <1610304247-11455-1-git-send-email-asafp@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v9] 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" From: Asaf Penso Adding more information about the release milestones. This includes the scope of change, expectations, etc. Signed-off-by: Asaf Penso Signed-off-by: Thomas Monjalon Acked-by: John McNamara Acked-by: Ajit Khaparde Acked-by: Bruce Richardson Acked-by: Andrew Rybchenko --- v2: fix styling format and add content in the commit message v3: change punctuation and avoid plural form when unneeded v4: avoid abbreviations, "Priority" in -rc, and reword as John suggests v5: note that release candidates may vary v6: merge RFC and proposal deadline, add roadmap link and reduce duplication v7: make expectations clearer and stricter v8: add tests, more fixes, maintainers approval and new API rules v9: make deadlines more explicit, remove confusing lines about fixes --- doc/guides/contributing/patches.rst | 83 +++++++++++++++++++++++++++-- 1 file changed, 78 insertions(+), 5 deletions(-) diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index b9cc6e67ae..5a83209474 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -164,6 +164,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines the :doc:`ABI policy ` and :ref:`ABI versioning ` guides. New external functions should also be added in alphabetical order. +* Any new API function should be used in ``/app`` test directory. + +* When introducing a new device API, at least one driver should implement it. + * Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``. See the :ref:`Release Notes section of the Documentation Guidelines ` for details. @@ -177,6 +181,8 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines * Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format. See the :ref:`Documentation Guidelines `. +* Code and related documentation must be updated atomically in the same patch. + Once the changes have been made you should commit them to your local repo. For small changes, that do not require specific explanations, it is better to keep things together in the @@ -185,11 +191,6 @@ Larger changes that require different explanations should be separated into logi A good way of thinking about whether a patch should be split is to consider whether the change could be applied without dependencies as a backport. -It is better to keep the related documentation changes in the same patch -file as the code, rather than one big documentation patch at the end of a -patchset. This makes it easier for future maintenance and development of the -code. - As a guide to how patches should be structured run ``git log`` on similar files. @@ -663,3 +664,75 @@ patch accepted. The general cycle for patch review and acceptance is: than rework of the original. * Trivial patches may be merged sooner than described above at the tree committer's discretion. + + +Milestones definition +--------------------- + +Each DPDK release has milestones that help everyone to converge to the release date. +The following is a list of these milestones together with +concrete definitions and expectations for a typical release cycle. +An average cycle lasts 3 months and have 4 release candidates in the last month. +Test reports are expected to be received after each release candidate. +The number and expectations of release candidates might vary slightly. +The schedule is updated in the `roadmap `_. + +.. note:: + Sooner is always better. Deadlines are not ideal dates. + + Integration is never guaranteed but everyone can help. + +Roadmap +~~~~~~~ + +* Announce new features in libraries, drivers, applications, and examples. +* To be published before the previous release. + +Proposal Deadline +~~~~~~~~~~~~~~~~~ + +* Must send an RFC (Request For Comments) or a complete patch of new features. +* Early RFC gives time for design review before complete implementation. +* Should include at least the API changes in libraries and applications. +* Library code should be quite complete at the deadline. +* Nice to have: driver implementation, example code, and documentation. + +rc1 +~~~ + +* Priority: libraries. No library feature should be accepted after -rc1. +* API changes or additions must be implemented in libraries. +* The API must include Doxygen documentation + 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 may be a draft sent in a separate series. +* The above should be sent to the mailing list at least 2 weeks before -rc1 + to give time for review and maintainers approval. +* If no review after 10 days, a reminder should be sent. +* Nice to have: example code (``/examples``) + +rc2 +~~~ + +* Priority: drivers. No driver feature should be accepted after -rc2. +* A driver change must include documentation + in the relevant .rst files (driver-specific and release notes). +* Driver changes should be sent to the mailing list before -rc1 is released. + +rc3 +~~~ + +* Priority: applications. No application feature should be accepted after -rc3. +* New functionality that does not depend on libraries update + can be integrated as part of -rc3. +* The application change must include documentation in the relevant .rst files + (application-specific and release notes if significant). +* Libraries and drivers cleanup are allowed. +* Small driver reworks. + +rc4 +~~~ + +* Documentation updates. +* Critical bug fixes only. -- 2.33.0