Re: [dpdk-dev] DPDK Release Status Meeting 31/05/2018

["Wiles, Keith" <keith.wiles@intel.com>]

> On May 31, 2018, at 12:18 PM, dev-bounces@dpdk.org wrote:
> 
> Minutes from the weekly DPDK Release Status Meeting.
> 
> The DPDK Release Status Meeting is intended for DPDK Committers to discuss
> the status of the master tree and sub-trees, and for project managers to
> track progress or milestone dates.
> 
> The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
> send me and email and I will send you the invite.
> 
> 
> Minutes 31 May 2018
> 
> Agenda:
> 
> * DPDK 18.05 release.
> * Retrospective on 18.05.
> * Testing of stable releases.
> 
> Participants:
> 
> * Intel
> * Cavium
> * Mellanox
> * NXP
> * 6Wind
> * RedHat
> 
> 
> DPDK 18.05 release.
> 
> * DPDK 18.08 "The Venky Release" is out. \o/
> * Thanks to all the maintainers and contributors.
> * See the release notes for the full stats:
>  http://dpdk.org/ml/archives/announce/2018-May/000204.html
> 
> 
> Retrospective on 18.05.
> 
> * What went well.
> 
>  * Largest DPDK release ever.
>  * Lots of contributors from all the main companies involved in networking.
>  * Collaboration on major features between companies in the community.
> 
> * What didn't go so well.
> 
>  * The release was very late and required a lot of release candidates.

More testing is always better and sooner then later is better.

>  * RC1 was late and low quality.
>  * Many major defects found in RC testing.
>  * Some reviews were slow or late.
> 
> * What can we do differently next time.
> 
>  * Should we change the number of releases per year from 4 to 3 or 2?
>  * Merge earlier from subtrees: every 7-10 days.

Knowing when a merge is scheduled could help if say it would be every Monday or Wednesday. I would not put it on a Friday as that tends to cause people having to work on the weekends. Maybe every Wednesday would be best. It allows the developers to know when patches are applied and allow for more testing before the first RC.

>  * Push patches earlier.
>  * Review patches more critically. Does every feature/patch need to go in.
>  * Use unit tests more
>    * Make them a requirement for any sizeable code.
>    * Make them easier to write/use/run.
>    * Add a make/meson target for generating coverage results from units
>      tests. Any volunteers?
>  * Hold more strictly to the release milestone dates.

I notice at times developers need to rebase on to master because of changes. Is this because of patches after theirs is applied before or do we need to have something in place to eliminate this rework?

Knowing when someone is going to introduce a big patch that may disturb or change many things effecting a patch would be nice to see a schedule produced by the developer as to when it will be push. I hope it would give more control for maintainers to schedule a given patch.
> 
> 
> Testing of stable releases.
> 
> * Luca Boccassi asked about testing of the stable release.
> * All major contributing companies should confirm test results on the stable
>  releases.
> * Luca will send an email to the list about it:
>  http://dpdk.org/ml/archives/dev/2018-May/103249.html
> 

Regards,
Keith