[dpdk-web] [PATCH 1/2] start 2.3 roadmap

[dpdk-web] [PATCH 1/2] start 2.3 roadmap

[Thomas Monjalon]

Add roadmap inputs from Intel
http://dpdk.org/ml/archives/dev/2015-November/029079.html
---
 dev/roadmap.html | 65 +++++++++++++++++---------------------------------------
 1 file changed, 20 insertions(+), 45 deletions(-)

diff --git a/dev/roadmap.html b/dev/roadmap.html
index 0594eee..5c73d85 100644
--- a/dev/roadmap.html
+++ b/dev/roadmap.html
@@ -40,58 +40,33 @@
 	<h2>Development roadmap</h2>
 	<p>Major known features and milestones may be noted here.
 	This list is obviously neither complete nor guaranteed.
-	<h3 id="22">Version 2.2 (end of November 2015)</h3>
+	<h3 id="23">Version 2.3 (end of March 2016)</h3>
 	<ul>
-		<li>queue information
+		<li>cgroup resource awareness
+		<li>hugetlbfs mount point size
+		<li>external mempool manager
+		<li>Intel resource director technology
+		<li>improve live migration
+		<li>tcpdump support
 		<li>speed capability
-		<li>statistics rework
-		<li>keep-alive
-		<li>merge physical and virtual devices handling
-		<li>OSv support
+		<li>generic tunneling
 		<li>Hyper-V driver
-		<li>Xen driver
-		<li>szedata2 driver
-		<li>mlx5 driver
-		<li>uio MSI-X
-		<li>e1000 Rx interrupt
-		<li>igb TSO
 		<li>ixgbe base update
-		<li>ixgbe VF TSO
-		<li>ixgbe X550 VF RSS
-		<li>ixgbe X550 flow director for VXLAN/NVGRE
-		<li>ixgbe X550 DCB
-		<li>ixgbe X550 IEEE1588
-		<li>i40e base update
-		<li>i40e Rx interrupt
-		<li>i40e DCB
-		<li>i40e filtering more flexible
-		<li>i40e GRE 32-bit key
-		<li>fm10k base update
-		<li>fm10k vector driver
+		<li>i40e flow director extension
+		<li>i40e VEB switching and floating VEB
+		<li>i40e IPGRE
+		<li>i40e VF MAC address
+		<li>i40e PCIe extended tag rework
 		<li>fm10k Rx interrupt
-		<li>fm10k TSO
-		<li>fm10k IEEE1588
-		<li>af_packet hotplug
-		<li>vmxnet3 hotplug
-		<li>xenvirt hotplug
-		<li>virtio TSO
-		<li>vhost multiqueue
-		<li>vhost optimization
-		<li>bonding dynamic RSS
+		<li>fm10k FTAG based forwarding
+		<li>virtio 1.0
+		<li>virtio for containers
+		<li>vhost TSO
 		<li>bonding mode 4 external state machine
-		<li>cryptodev API
-		<li>Quick Assist driver
-		<li>AES-NI multi-buffer driver
 		<li>more LPM hops
-		<li>packet framework enhanced for edge router
-		<li>lightweight thread example
-		<li>IEEE1588 example
-		<li>ethtool example
-	</ul>
-	<h3 id="23">Version 2.3 (end of March 2016)</h3>
-	<ul>
-		<li>automatic port binding
-		<li>hardware support listing app
+		<li>SNOW 3G cipher
+		<li>IPsec example
+		<li>packet framework enhancements for edge router
 	</ul>
 	<p>The 3 major release cycles per annum system is designed to allow DPDK
 	to keep evolving at a rapid pace while giving enough opportunity
-- 
2.5.2

[dpdk-web] [PATCH 2/2] update release scheduling for 2016

[Thomas Monjalon]

It may be a bit long to wait 4 months for a feature.
Shorten release cycle progressively from 4 months to 3 months
and try to preserve some of the major holiday periods
(February, May, August, December).
---
 dev/roadmap.html |  87 ++++++++++++++++++++++++++-----------------------------
 dev/schedule.png | Bin 27965 -> 0 bytes
 2 files changed, 41 insertions(+), 46 deletions(-)
 delete mode 100644 dev/schedule.png

diff --git a/dev/roadmap.html b/dev/roadmap.html
index 5c73d85..37a8d88 100644
--- a/dev/roadmap.html
+++ b/dev/roadmap.html
@@ -68,57 +68,52 @@
 		<li>IPsec example
 		<li>packet framework enhancements for edge router
 	</ul>
-	<p>The 3 major release cycles per annum system is designed to allow DPDK
-	to keep evolving at a rapid pace while giving enough opportunity
-	to implement and evolve <a href="/dev">contributions</a>.
-	<p>A minor version x.y.1 may be released to integrate some fixes or
-	minor changes without waiting several monthes for the next major version.
 	<h3 id="cycle">Cycle model</h3>
-	<img src="schedule.png" alt="schedule">
-	<p>The Merge Window will open once the previous release is complete,
-	and will close 8 weeks before the release date.
-	First version of a new feature can be submitted only during this period.
-	Features that miss the Merge Window will be deferred until the next release.
-	<p>Following this, there is a Review Period to allow finishing reviews,
-	reworks and test patches.
-	Updated versions of patches (v2, v3, etc.) will be submitted to address comments.
-	For patches that are submitted early in the Merge Window,
-	this Review Period actually begin as soon as the v1 patchset is submitted.
-	For simplicity, this overlap is not shown in the diagram.
-	<p>At the end of the Review Period, the first Release Candidate is out.
-	New features which were not properly reviewed and acknowledged at this time
-	will be postponed to the next releases.
-	<p>A period of testing will follow, with bug fixes submitted to fix issues
-	found during testing, and additional Release Candidates built as required.
-	<p>A final Release Candidate will be built 2 weeks before the release date,
-	and will undergo a final Regression Test period.
-	In order to ensure the stability of the release,
-	only fixes to high priority issues will be accepted during this time.
-	Fixes to lower priority issues will be deferred to a subsequent release.
-	<h3 id="dates">Planning</h3>
-	<p>Applying this model to the 2015 releases, the following are the major milestones:
-	<p>Release 2.0
+	<p>A typical release should be done after 3 months (was 4 months during 2015).
+	<p>It is designed to allow DPDK to keep evolving at a rapid pace while
+	giving enough opportunity to review, discuss and improve the contributions.
+	<p>The merge window will open once the previous release is complete.
+	First version of a new feature must be submitted before the proposal deadline.
+	Features that miss this first period will be deferred until the next release.
+	<p>Updated versions of patches (v2, v3, etc.) will be submitted to address comments.
+	The new features must be properly reviewed, tested and accepted before the
+	integration deadline. Otherwise, they will be postponed to the next releases.
+	<p>At the end of the merge window, the first release candidate is out.
+	<p>The last period is 1 month long and is dedicated to bug fixing.
+	<h3 id="dates">Scheduling</h3>
+	<p>The release cycles are progressively shorten during 2016.
+	<p>Release 16.04
 	<ul>
-		<li>Merge Window: 1st December 2014 to 30th January 2015
-		<li>Review Period: 2nd February to 20th February
-		<li>RC Testing: 23rd February to 13th March
-		<li>Regression Test: 16th March to 27th March
-		<li>Release: 31st March
+		<li>Proposal deadline: January 31
+		<li>Integration deadline: March 10
+		<li>Release: April 7
 	</ul>
-	<p>Release 2.1
+	<p>Release 16.07
 	<ul>
-		<li>Merge Window: 1st April to 5th June
-		<li>Review Period: 8th June to 26th June
-		<li>RC Testing: 29th June to 17th July
-		<li>Regression Test: 20th July to 31st July
-		<li>Release: 31st July
+		<li>Proposal deadline: May 8
+		<li>Integration deadline: June 16
+		<li>Release: July 18
 	</ul>
-	<p>Release 2.2
+	<p>Release 16.11
 	<ul>
-		<li>Merge Window: 1st August to 2nd October
-		<li>Review Period: 5th October to 30th October
-		<li>RC Testing: 2nd November to 13th November
-		<li>Regression Test: 16th November to 27th November
-		<li>Release: 30th November
+		<li>Proposal deadline: August 28
+		<li>Integration deadline: September 30
+		<li>Release: November 2
+	</ul>
+	<p>Release 17.02
+	<ul>
+		<li>Release: February 1
+	</ul>
+	<p>Release 17.05
+	<ul>
+		<li>Release: May 2
+	</ul>
+	<p>Release 17.08
+	<ul>
+		<li>Release: August 1
+	</ul>
+	<p>Release 17.11
+	<ul>
+		<li>Release: November 2
 	</ul>
 </section>
diff --git a/dev/schedule.png b/dev/schedule.png
deleted file mode 100644

-- 
2.5.2