[v8] doc: add release milestones definition

  From: Asaf Penso <asafp@nvidia.com>

Adding more information about the release milestones.
This includes the scope of change, expectations, etc.

Signed-off-by: Asaf Penso <asafp@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
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
---
 doc/guides/contributing/patches.rst | 85 +++++++++++++++++++++++++++--
 1 file changed, 80 insertions(+), 5 deletions(-)
  

On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> From: Asaf Penso <asafp@nvidia.com>
> 
> Adding more information about the release milestones.
> This includes the scope of change, expectations, etc.
> 
> Signed-off-by: Asaf Penso <asafp@nvidia.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: John McNamara <john.mcnamara@intel.com>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> 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
> ---
>  doc/guides/contributing/patches.rst | 85 +++++++++++++++++++++++++++--
>  1 file changed, 80 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index b9cc6e67ae..ef784d0f99 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 <abi_policy>` and :ref:`ABI versioning <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.
> +

ack

>  * 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 <doc_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 <doc_guidelines>`.
>  
> +* Code and related documentation must be updated atomically in the same patch.
> +

ack

>  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,77 @@ 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 <https://core.dpdk.org/roadmap/#dates>`_.
> +
> +.. 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 first day of the release cycle.
> +
> +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).
> +* The above should be sent to the mailing list at least 2 weeks before -rc2.

Is 'the above' driver changes? 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, 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?

> +* 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.

> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
>
  

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.
  

On 8/26/21 1:11 PM, Thomas Monjalon wrote:
> From: Asaf Penso <asafp@nvidia.com>
> 
> Adding more information about the release milestones.
> This includes the scope of change, expectations, etc.
> 
> Signed-off-by: Asaf Penso <asafp@nvidia.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: John McNamara <john.mcnamara@intel.com>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

LGTM, just one nits below

Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

> +Roadmap
> +~~~~~~~
> +
> +* Announce new features in libraries, drivers, applications, and examples.
> +* To be published before the first day of the release cycle.

What is the first day of the release cycle? Proposal deadline?
Or the first day just after the previous release?
  

03/09/2021 14:26, Andrew Rybchenko:
> On 8/26/21 1:11 PM, Thomas Monjalon wrote:
> > +* Announce new features in libraries, drivers, applications, and examples.
> > +* To be published before the first day of the release cycle.
> 
> What is the first day of the release cycle? Proposal deadline?
> Or the first day just after the previous release?

Just after the previous release. I will be more explicit in v9, thanks.
  

On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> 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?
> 

Can say 'Driver change' again, it is not too long from 'The above', but no
strong opinion.

>> 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.
> 

Got the intention now, perhaps we can word like that, '... should be sent before
-rc1 released ...'

>> 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?
> 

Agree that a week is short, I just thought that it is happening in practice, but
if you don't mind lets keep your original proposal (-rc1 deadline for first
version of driver patches) with the option to update it later if we have
difficulties to keep it.

>>> +* 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?
> 

I think we can keep it, good to highlight one of the major tasks for -rc2 is to
fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.

>>> +
>>> +rc4
>>> +~~~
>>> +
>>> +* Documentation updates.
>>> +* Critical bug fixes.
> 
> 
>
  

03/09/2021 17:35, Ferruh Yigit:
> On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> > 02/09/2021 18:33, Ferruh Yigit:
> >> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> >>> +* 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?
> 
> I think we can keep it, good to highlight one of the major tasks for -rc2 is to
> fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.

Actually I think it is better to remove.
It looks weird to have it only in -rc2.
  

On Tue, Sep 14, 2021 at 12:53 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 03/09/2021 17:35, Ferruh Yigit:
> > On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> > > 02/09/2021 18:33, Ferruh Yigit:
> > >> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> > >>> +* 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?
> >
> > I think we can keep it, good to highlight one of the major tasks for -rc2 is to
> > fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.
>
> Actually I think it is better to remove.
> It looks weird to have it only in -rc2.
I see you have sent the new version and it is looking really good.

We can mention that bug fixes are welcome at any point in the cycle,
but priority will be given to critical fixes close to the release date.

>
>
  

14/09/2021 18:11, Ajit Khaparde:
> On Tue, Sep 14, 2021 at 12:53 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 03/09/2021 17:35, Ferruh Yigit:
> > > On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> > > > 02/09/2021 18:33, Ferruh Yigit:
> > > >> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> > > >>> +* 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?
> > >
> > > I think we can keep it, good to highlight one of the major tasks for -rc2 is to
> > > fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.
> >
> > Actually I think it is better to remove.
> > It looks weird to have it only in -rc2.
> I see you have sent the new version and it is looking really good.
> 
> We can mention that bug fixes are welcome at any point in the cycle,

I hope it is obvious.

> but priority will be given to critical fixes close to the release date.

Yes it says critical bug fixes only.