From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <aconole@redhat.com> Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id D66585F65; Fri, 20 Apr 2018 17:52:09 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 081B7722ED; Fri, 20 Apr 2018 15:52:09 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 562812026DFD; Fri, 20 Apr 2018 15:52:08 +0000 (UTC) From: Aaron Conole <aconole@redhat.com> To: Kevin Traynor <ktraynor@redhat.com> Cc: Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, web@dpdk.org, dev@dpdk.org, techboard@dpdk.org, bluca@debian.org, yliu@fridaylinux.org, christian.ehrhardt@canonical.com, yskoh@mellanox.com References: <20180309133612.19927-1-thomas@monjalon.net> <2746771.jHPYkc9GPR@xps> <b8d413f2-e316-8a5e-564b-f990a070f7bd@intel.com> <2289123.B0I2yLRMB9@xps> <bfe0d6df-7214-33b9-e941-aed120b7d969@redhat.com> Date: Fri, 20 Apr 2018 11:52:07 -0400 In-Reply-To: <bfe0d6df-7214-33b9-e941-aed120b7d969@redhat.com> (Kevin Traynor's message of "Thu, 19 Apr 2018 10:38:10 +0100") Message-ID: <f7tfu3p6fko.fsf@dhcp-25.97.bos.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 20 Apr 2018 15:52:09 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 20 Apr 2018 15:52:09 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'aconole@redhat.com' RCPT:'' Subject: Re: [dpdk-dev] [dpdk-web] [PATCH v2] update stable releases roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 20 Apr 2018 15:52:10 -0000 Kevin Traynor <ktraynor@redhat.com> writes: > On 04/18/2018 02:28 PM, Thomas Monjalon wrote: >> 18/04/2018 14:28, Ferruh Yigit: >>> On 4/18/2018 10:14 AM, Thomas Monjalon wrote: >>>> 18/04/2018 11:05, Ferruh Yigit: >>>>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote: >>>>>> - <p>Typically a new stable release version follows a mainline release >>>>>> - by 1-2 weeks, depending on the test results. >>>>>> + <p>The first stable release (.1) of a branch should follow >>>>>> + its mainline release (.0) by at least two months, >>>>>> + after the first release candidate (-rc1) of the next branch. >>>>> >>>>> Hi Thomas, >>>>> >>>>> What this change suggest? To be able to backport patches from rc1? >>>> >>>> Yes, it is the proposal we discussed earlier. >>>> We can wait one week after RC1 to get some validation confirmation. >>>> Do you agree? >>> >>> This has been discussed in tech-board, what I remember the decision was to wait >>> the release to backport patches into stable tree. >> > > Any minutes? I couldn't find them > >> It was not so clear to me. >> I thought post-rc1 was acceptable. The idea is to speed-up stable releases >> pace, especially first release of a series. >> >> > > I think timing of stable releases and bugfix backports to the stable > branch are two separate items. > > I do think that bugfix backports to stable should happen on a regular > basis (e.g. every 2 weeks). Otherwise we are back to the situation where > if there's a bugfix after a DPDK release, a user like (surprise, > surprise) OVS may not be able to use that DPDK version for ~3 months. > > Someone who wants to get the latest bugfixes can just take the latest on > the stable branch and importantly, can have confidence that the > community has officially accepted those patches. If someone requires > stable to be validated, then they have to wait until the release. +1 - this seems to make the most sense to me. Keep the patches flowing, but don't label/tag it until validation. That serves an additional function: developers know their CC's to stable are being processed. > Kevin.