release schedule change proposal
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)
This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal period
I propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)
New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.
In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0
proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0
Opinions?
Quoted 37 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0
Quoted 1 line
Opinions?
We upload only LTS releases to Debian/Ubuntu, so as long as those stay the same as it is proposed here, no problem for us.
Signature · 2 lines
Kind regards, Luca Boccassi
Quoted 6 lines · Luca Boccassi
Quoted 4 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)
Quoted 7 lines
Quoted 7 lines
This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)
+1
Quoted 34 lines
Quoted 26 lines
New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0Quoted 1 line
Opinions?
We upload only LTS releases to Debian/Ubuntu, so as long as those stay the same as it is proposed here, no problem for us.
--
Kind regards,
Luca Boccassi
Quoted 37 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0
Quoted 3 lines
Opinions?
Someone else might comment if they spot something, but to me looks ok for RH distro and OVS project.
RH distro is also using DPDK .11 who's release date is not changing. (+cc Timothy/Flavio)
For OVS project, it only integrates DPDK .11 release too and aims to do that by EOY to make the next OVS release. DPDK stable releases are integrated into older OVS branches when available. I don't think older OVS branch releases have a strict release schedule and having the latest stable DPDK release is not a blocker anyway. (+cc Ilya/Ian/ovs-discuss)
Quoted 11 lines · On Mon, 15 Nov 2021 15:58:15 +0100 Thomas Monjalon <[email protected]> wrote:
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)
This nicely adapts to the natural slowdown due to holidays in December and August.
Quoted 1 line
Opinions?
Atomic Rules has been releasing our Arkville product in lockstep with DPDK for the past 19 quarters. Our FPGA solution has the added burden of testing with async releases of FPGA vendor CAD tools. Although we have gotten used to the quarterly cadence, for the reasons given by Thomas and others, Atomic Rules supports the move to a three release per year schedule.
Shepard Siegel, CTO and Founder
atomicrules.com
Quoted 20 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, November 15, 2021 5:39 PM
To: Luca Boccassi <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; dpdk-dev <[email protected]>; [email protected]
Subject: Re: release schedule change proposalQuoted 11 lines · Luca Boccassi
Quoted 9 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal period
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
I propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)+1
+1
Quoted 36 lines
Quoted 36 lines
Quoted 28 lines
New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0Quoted 1 line
Opinions?
We upload only LTS releases to Debian/Ubuntu, so as long as those stay the same as it is proposed here, no problem for us.
--
Kind regards,
Luca Boccassi
Quoted 29 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0
Quoted 8 lines
proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0
+1
Quoted 4 lines
Opinions?
Thanks Kevin for bringing this up.
See below.
Quoted 38 lines · Kevin Traynor
Quoted 37 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0
Quoted 7 lines
Quoted 3 lines
Opinions?
Someone else might comment if they spot something, but to me looks ok for RH distro and OVS project.
That is my impression as well.
Quoted 4 lines
RH distro is also using DPDK .11 who's release date is not changing. (+cc Timothy/Flavio)
My concern is if patches would get delayed to be merged because of this change, but I don't think that will be the case.
Quoted 6 lines
For OVS project, it only integrates DPDK .11 release too and aims to do that by EOY to make the next OVS release. DPDK stable releases are integrated into older OVS branches when available. I don't think older OVS branch releases have a strict release schedule and having the latest stable DPDK release is not a blocker anyway. (+cc Ilya/Ian/ovs-discuss)
I agree.
fbl
Quoted 42 lines · Kevin Traynor
Quoted 37 lines · Thomas Monjalon
For the last 5 years, DPDK was doing 4 releases per year, in February, May, August and November (the LTS one):
.02 .05 .08 .11 (LTS)This schedule has multiple issues:
- clash with China's Spring Festival
- too many rushes, impacting maintainers & testers
- not much buffer, impacting proposal periodI propose to switch to a new schedule with 3 releases per year:
.03 .07 .11 (LTS)New LTS branch would start at the same time of the year as before. There would be one less intermediate release during spring/summer:
.05 and .08 intermediate releases would become a single .07. I think it has almost no impact for the users.
This change could be done starting next year.In details, this is how we could extend some milestones:
ideal schedule so far (in 13 weeks):
proposal deadline: 4
rc1 - API freeze: 5
rc2 - PMD features freeze: 2
rc3 - app features freeze: 1
rc4 - last chance to fix: 1
release: 0proposed schedule (in 17 weeks):
proposal deadline: 4
rc1 - API freeze: 7
rc2 - PMD features freeze: 3
rc3 - app features freeze: 1
rc4 - more fixes: 1
rc5 - last chance buffer: 1
release: 0Quoted 3 lines
Opinions?
Quoted 6 lines
Someone else might comment if they spot something, but to me looks ok for RH distro and OVS project.
RH distro is also using DPDK .11 who's release date is not changing. (+cc Timothy/Flavio)
For OVS project, it only integrates DPDK .11 release too and aims to do that by EOY to make the next OVS release. DPDK stable releases are integrated into older OVS branches when available. I don't think older OVS branch releases have a strict release schedule and having the latest stable DPDK release is not a blocker anyway. (+cc Ilya/Ian/ovs-discuss)
I agree that this schedule change doesn't change much for OVS.
One thing to highlight though: Change of main release schema seems to directly impact schedule of stable releases. In this case, interval between DPDK stable releases increases from 3+ to 4+ months. This might be a long time to wait for certain bug fixes, especially if OVS needs to skip one of the DPDK stable releases due to issues introduced in it. Anyway, doesn't sound like something critical to me.
Bets regards, Ilya Maximets.