Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition

18/05/2021 13:57, Ferruh Yigit:

On 3/28/2021 8:00 PM, Thomas Monjalon wrote:

quoted

From: Asaf Penso <redacted>

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

[...]

quoted

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

quoted

+* New API should be defined and implemented in libraries.
+* The API should include Doxygen documentation

s/should/must

OK

quoted

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

quoted

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

quoted

+* A driver change should include documentation

s/should/must

Sometimes there is no doc to change. Is "must" confusing?

quoted

+  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

quoted

+* The application should include documentation in the relevant .rst files
+  (application-specific and release notes if significant).

s/should/must

quoted

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

quoted

+* Libraries and drivers cleanup are allowed.
+* Small driver reworks.
+* Critical and minor bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.