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

[Thomas Monjalon]

18/05/2021 13:57, Ferruh Yigit:
> On 3/28/2021 8:00 PM, Thomas Monjalon wrote:
> > From: Asaf Penso <asafp at nvidia.com>
> > 
> > Adding more information about the release milestones.
> > This includes the scope of change, expectations, etc.
[...]
> > +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.

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

OK

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

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

> > +* A driver change should include documentation
> 
> s/should/must

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

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

> > +* The application should include documentation in the relevant .rst files
> > +  (application-specific and release notes if significant).
> 
> s/should/must
> 
> > +* 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.

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