From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65FF5C433F5 for ; Fri, 3 Sep 2021 11:50:58 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 8DD9060238 for ; Fri, 3 Sep 2021 11:50:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8DD9060238 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=monjalon.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C93CD40E64; Fri, 3 Sep 2021 13:50:56 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 6426340E3C for ; Fri, 3 Sep 2021 13:50:55 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F33D35C0159; Fri, 3 Sep 2021 07:50:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 03 Sep 2021 07:50:53 -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=fm2; bh= SUFWZVUO2CovRa1fmfY6wommvm6TPv8FqVKJKNLxCBU=; b=hkUtTZ2d7SqUvyM4 hMoAjk3pUC6ddb8w1mqGfZf5kpV017h4aY0pxxwb2WvYhgE81z6docDM7mbQCHu3 mL/OJm1WypTAxUcgVhiw4/rEx4t+jO2i2o7gs+jBflp0hetzrOi9yurAhMJtZtUa E7bDXQQxCwsvRNtcLMTYoQ4AtnZLLAnmmW19lXWVpX5cCSlF3UL8S9cC7AHSAOtb VHzwDI3XNW2UwRDHMfrnd1N8xGSsjzVwnTGWiqvP5tZrfok523JQiB6VOW3SV0gR LSX6/Zz58XubNST3axphwWQ84y8R0J9Zv4sOngm5U9GJpn8SEiKh2XjHpThel0I/ iDO/bQ== 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=fm3; bh=SUFWZVUO2CovRa1fmfY6wommvm6TPv8FqVKJKNLxC BU=; b=M37bJ59M9fvUPcjH5ViWKI8Xm+B1+K42Eg9cm4kcN9J+V6GkmV35Xyeiy YktzFgI5NnTTw6uuxge3lJjRCSjshzrYKrwX7dudNAJJC0w1jv8YD0IES/g8udbO F310FLEeMcoWlFb31XUlwQ2M8LMCvcOJ8PvBu3CQJTw9UambdKtlJBUdxzisvi19 niPAE7btv5eyFywAuHD53lCpc4x8SmGYyeXisxRSGGdT32oHxTLklPYlLq9oh3OE tKoyDCef2Y147WuwkFlDoVTtzRoE3sUIrkyXojfLkHxTsbWv2yaEAIJo6ssrwq/B fnARCMwbu9rWBzO5T+H4HoxsysNTw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddvjedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 Sep 2021 07:50:52 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, david.marchand@redhat.com, Asaf Penso , John McNamara , Ajit Khaparde , Bruce Richardson Date: Fri, 03 Sep 2021 13:50:50 +0200 Message-ID: <2766038.zeebYbSGT0@thomas> In-Reply-To: References: <1610304247-11455-1-git-send-email-asafp@nvidia.com> <20210826101102.709502-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8] 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" 02/09/2021 18:33, Ferruh Yigit: > On 8/26/2021 11:11 AM, Thomas Monjalon wrote: > > +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). > > +* The above should be sent to the mailing list at least 2 weeks before -rc2. > > Is 'the above' driver changes? Yes. Do you think to a more explicit wording? > It is good the have all driver changes two weeks > before -rc2 but taking into account that overall time between -rc1 & -rc2 is 3/4 > weeks, No, time between rc1 and rc2 is usually 2 weeks, so it means having drivers features at the time of -rc1. > two weeks before -rc2 may be hard to do practically. > We may go with this and try and evaluate later or reduce the requirement to one > week before -rc2, what do you think? This is for the first version of the PMD features. Then there are reviews and new iterations. I think one week is too short. What do you think of 10 days? > > +* Any issue found in -rc1 should be fixed. > > + > > +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. > > +* Critical and minor bug fixes. > > As mentioned before, my concern is this may create false impression that bugs > are fixed only in this phase. What about remove this line completely and update > below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more > clear. I had added in -rc2: "Any issue found in -rc1 should be fixed." Do you want to remove it as well? > > + > > +rc4 > > +~~~ > > + > > +* Documentation updates. > > +* Critical bug fixes.