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 A514CA0547; Wed, 19 May 2021 14:16:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2491740041; Wed, 19 May 2021 14:16:07 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 118A14003F for ; Wed, 19 May 2021 14:16:06 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 868BB5C0035; Wed, 19 May 2021 08:16:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 19 May 2021 08:16:04 -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= 7H7Im+sn3HztyZT5L1YwvIkFskO2+JGhlwKKqwkmyoc=; b=qK/22klKjnTJaOPC jq9GcOJ5MMYb0ZzkwFQhQRnzBHGqEMqDlD7CcVEiy6kZKvlSIXZaIpszVfsvlhI5 RkGf0Os84IkV48eGkpTqQLt/t7E6SahVWSZUzwu5VIArzFiAYgVBzqIhz8ZNoDRH JXC7UN2DZxtZMxF+ORqE2TrBwDzWYJPQU45inEpIyNJKwsluGyTz2PBZWoNuMW9D Xww+MjpNvdUv3XrrfUiLZuqaa7Cf7SPTBNUFM6sGroyvc4Bb9i5XXCJkOaOw5kiK Hp3Y0wy/3SU2G9el2ulCETE0Oz/JNxlTwfn+dZDrNMfDcwC6LnhMSs+S/UwRplOp ItL+iQ== 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=7H7Im+sn3HztyZT5L1YwvIkFskO2+JGhlwKKqwkmy oc=; b=gCxuRCJ+b7I1ivodtcGvH1tWAWK9XHPecsG5tbmnno/pj7X5X+vIadhYB mWgAbnrQB3AxWRgpJr7rvqqEUpqBd/hGkwWnxycrTHvrT6/87//R5OoQuikc3k/v 33a2dTzHJcybet96ys+gWcgDfXwTqfLC0OvrV+mQhZ6x2981c4E0XX/WJGZWHYpO IQwmxB2y+nziybuXUqWcsNjnDFZfR05zHxU6Ir45sdN4r0dQdEFQkDYwq9BwwfRf cW4kqvg/UQkX5WXEXKGy3QoOKmqrcb2RfVnS1fjI/ZKJccsZCsfkJtX+dlC1Hko1 fyr2bNCdKynUxkcYKVyL4zOcy6ehQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeiledggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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; Wed, 19 May 2021 08:16:03 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, david.marchand@redhat.com, Asaf Penso , John McNamara , Ajit Khaparde Date: Wed, 19 May 2021 14:16:01 +0200 Message-ID: <3621541.CEykRqKYJk@thomas> In-Reply-To: <4f2c6803-5c20-6583-9439-1db66cbfe5d9@intel.com> References: <1610304247-11455-1-git-send-email-asafp@nvidia.com> <20210518164303.4108310-1-thomas@monjalon.net> <4f2c6803-5c20-6583-9439-1db66cbfe5d9@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7] 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" 19/05/2021 13:58, Ferruh Yigit: > On 5/18/2021 5:43 PM, Thomas Monjalon wrote: > > 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 > > --- > > 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 > > --- > > doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++ > > 1 file changed, 72 insertions(+) > > > > diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst > > index 6dbbd5f8d1..4d70e326c5 100644 > > --- a/doc/guides/contributing/patches.rst > > +++ b/doc/guides/contributing/patches.rst > > @@ -177,6 +177,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 > > @@ -660,3 +662,73 @@ 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, > > Is the ',' correct here. John may help better. > > > +for a typical release cycle (3 months ending after 4 release candidates). > > Can it be better to put explicitly that a regular release cycle takes around 3 > months and it mostly has 4 release candidates, instead of giving this shortly > within parenthesis? > > > +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. > > + > > +1 > > > + Integration is never guaranteed but everyone can help. > > + > > +Roadmap > > +~~~~~~~ > > + > > +* Announce new features in libraries, drivers, applications, and examples. > > Do we need to call out the components, what about "Announce new features for > next release." The idea was to insist that all can be announced, including apps. > Is it fair to say features announced with a roadmap will get more priority > against the features that are not announced? It should be discussed in a separate patch I think. > > +* To be published before the first day of the release cycle. > > + > > +Proposal Deadline > > Does it have any value to document something like this: > > release start - proposal deadline: Initial development phase > proposal deadline - rc1: review / update / review phase > rc1 - release: test / update / test phase I don't know. > > +~~~~~~~~~~~~~~~~~ > > + > > +* Must send an RFC or a complete v1 patch. > > The subject is missing, it is developers, but would it be better to say > something like: > > An RFC (Request For Comment) or first version of the implementation must be > ready before deadline for the feature to be taken into account for the release. I was trying to keep it short. > > +* Early RFC gives time for design review before complete implementation. > > +* Should include at least the API changes in libraries and applications. > > Again subject is missing, > > Implementation should include ... I'm afraid it will become boring. > > +* Library code should be quite complete at the deadline. > > +* Nice to have: driver implementation (full or draft), example code, and documentation. > > This is talking about driver/example/documentation update related to a library > implementation, right? Right > Otherwise for the standalone driver/example implementation, isn't the target to > send them before proposal deadline? Yes > > + > > +rc1 > > +~~~ > > + > > +* Priority: libraries. No library feature should be accepted after -rc1. > > +* New API must be defined and implemented in libraries. > > Not sure about the value of "defined", why not just "new API must be implemented > in libraries". Also I guess it doesn't need to 'new'. OK > Also another big step here is it needs to approved by its maintainers. > > What about something like: > > API changes or additions must be implemented and approved by their maintainers. Yes good idea. > And as we know reviews can be bottleneck perhaps we can add a note on that too, > like: Developer should send a reminder for the patches that has not reviewed for > more than two weeks. ?? Yes, 10 days? > > +* 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. > > Above 2/3 bullets are the conditions for a feature to be merged, it is not > directly related to the milestone, should we have separate section to document > the expectation to upstream a new API? Yes, you're right but I feel it has a better value here as a complete checklist. > > +* The above should be sent to the mailing list at least 2 weeks before -rc1. > > +* Nice to have: example code (``/examples``) > > + > > I think we should mention that we expect test result from community after -rc1, > if this is to document the process. We expect tests after each -rc, so it would better fit as a general comment in the schedule introduction. > > +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. > > + > > I think testing and fixing issues found in the -rc1 is the big focus of the > -rc2. But we don't mention of the testing at all. Again I guess this is based on > the confusion if these descriptions define process or todo list for the developers. I would like to have both at the same place, so I agree we should mention fixing any issue found in previous stages. > > +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. > > Can this cause misunderstanding that fixes are merged for -rc3 (after -rc2)? > Can we highlight that fixes can be sent and merged anytime until -rc4, only > after -rc4 there is a restriction and only critical fixes are accepted? I think we should mention "any fix" for -rc2, and "all accepted" for -rc1 to remove confusion. > > + > > +rc4 > > +~~~ > > + > > +* Documentation updates. > > +* Critical bug fixes.