From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id 7EE10DED; Tue, 1 May 2018 16:16:22 +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 A5B3281A88A2; Tue, 1 May 2018 14:16:21 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0D1D72024CA1; Tue, 1 May 2018 14:16:21 +0000 (UTC) From: Aaron Conole To: Thomas Monjalon Cc: Luca Boccassi , Ferruh Yigit , Kevin Traynor , web@dpdk.org, dev@dpdk.org, techboard@dpdk.org, yliu@fridaylinux.org, christian.ehrhardt@canonical.com, yskoh@mellanox.com References: <20180309133612.19927-1-thomas@monjalon.net> <71571fa0-f2c1-707a-235f-45ca938cc651@intel.com> <1524650607.23292.6.camel@debian.org> <1906771.vQqTW93QMP@xps> Date: Tue, 01 May 2018 10:16:20 -0400 In-Reply-To: <1906771.vQqTW93QMP@xps> (Thomas Monjalon's message of "Mon, 30 Apr 2018 12:47:32 +0200") Message-ID: 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.8]); Tue, 01 May 2018 14:16:21 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 01 May 2018 14:16:21 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 14:16:22 -0000 Thomas Monjalon writes: > 25/04/2018 12:03, Luca Boccassi: >> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote: >> > On 4/20/2018 4:52 PM, Aaron Conole wrote: >> > > Kevin Traynor 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: >> > > > > > > > > -

Typically a new stable release version >> > > > > > > > > follows a mainline release >> > > > > > > > > - by 1-2 weeks, depending on the test results. >> > > > > > > > > +

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. >> > >> > Are stable trees verified? >> >> Verification is one issue - so far, Intel and ATT have provided time >> and resources to do some regression tests, but only at release time >> (before tagging). And it has been a manual process. >> It would be great if more companies would step up to help - and even >> better if regressions could be automated (nightly job?). >> >> The other issue is deciding when a patch is "good to go" - until now, >> the criteria has been "when it's merged into master". >> So either that criteria needs to change, and another equally >> "authoritative" is decided on, or patches should get reviewed and >> merged in master more often and more quickly :-P >> >> We also have not been looking directly at the the various -next trees, >> as things are more "in-flux" there and could be reverted, or clash with >> changes from other trees - hence why we merge from master. > > Yes, backporting from master is definitely the right thing to do. > Backporting more regularly would be also an improvement. > There will be always the question of the bug-free ideal in stable > branches. I agree we need more help to validate the stable branches. > But realistically, it will never be perfect. > > So the questions are: > - What we must wait before pushing a backport in the stable tree? > - What we must wait before tagging a stable release? > > I think it is reasonnable to push backports one or two weeks after > it is in the master branch, assuming master is tested by the community. > If a corner case is found later, it will be fixed with another patch. +1 - I agree here. Folks who truly care about 'validated stable' (whatever definition that takes) will only use a labeled version anyway. OTOH, developers who want to see that their patches are landing in stable (and more over, who want to ensure that their proposed backports are actually complete - which is more relevant w.r.t. hardware), shouldn't have to wait for the label. Most other projects work this way, as well. Keep pulling in the relevant patches from master to the stable branch(es). Do the official label / release at a certain point in time relative to the main release (or as needed in the case of "oh no, a serious bug here"). > That's why it's important to wait a validation period (happening after > each release candidate) before tagging a stable release. > So, if we are aware of a regression in the master branch, which has been > backported, we can wait few more days to fix it. > The last thing we need to consider before tagging, is the validation of > the stable release itself. Are we able to run some non-regression tests > on the stable branch if it is ready few days after a RC1?