From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id ADEB25F14; Wed, 25 Apr 2018 12:03:30 +0200 (CEST) Received: by mail-wm0-f66.google.com with SMTP id l16so5776629wmh.2; Wed, 25 Apr 2018 03:03:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=dbZ5SHjzTA7cFQ9W6j6z3Z2yrIgAQSTBKsKVmbt6dTU=; b=qJGfz5VzELEOzRCTZt+fl8MK1VTmfW1WyRLgyOXFRHksvfRcap160ws2EPKFew6NWF zHygPfyEVrt0F71tboH5FmgA6UaMwhI6pRahjDjkWYA65sDt/Q+M4qMm0hz2Lmkwvh9W FusV3rbnngNbshfxDQvx3BbdlF6cvCjlwYO5E6XQHF0H+gLMb5DqXYYITu3hqutBY65w LxXXoFeCDys49Htu0FIHZDn67Y+jIn+PQ1lpMhbSZqpbotaC2vn/5Rzw3P/3Um8qKjaE 1sW99+yOmGiRTm5aAT77NT+XELxMklLZPYrbuzHj8jFJ30tmty60jtuOG4IiesaBCoDM 4c9g== X-Gm-Message-State: ALQs6tDr/FEg+29ly/ndYtUDVOrrM6GusDcmfwPlRd/8fOxFCgdWp3Ey IU2flZMtMmyE55Mnqro1Jqc= X-Google-Smtp-Source: AIpwx495liEIXGluUYr6QMjFFZFXfCnc6Wj8b8fpxX5Ug+AzPdbnq9VdPYt1B5GarM9kYNi/tAcIuQ== X-Received: by 10.28.122.3 with SMTP id v3mr13718884wmc.81.1524650610293; Wed, 25 Apr 2018 03:03:30 -0700 (PDT) Received: from localhost (slip139-92-244-193.lon.uk.prserv.net. [139.92.244.193]) by smtp.gmail.com with ESMTPSA id p35-v6sm23394696wrb.12.2018.04.25.03.03.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Apr 2018 03:03:29 -0700 (PDT) Message-ID: <1524650607.23292.6.camel@debian.org> From: Luca Boccassi To: Ferruh Yigit , Aaron Conole , Kevin Traynor Cc: Thomas Monjalon , web@dpdk.org, dev@dpdk.org, techboard@dpdk.org, yliu@fridaylinux.org, christian.ehrhardt@canonical.com, yskoh@mellanox.com Date: Wed, 25 Apr 2018 11:03:27 +0100 In-Reply-To: <71571fa0-f2c1-707a-235f-45ca938cc651@intel.com> References: <20180309133612.19927-1-thomas@monjalon.net> <2746771.jHPYkc9GPR@xps> <2289123.B0I2yLRMB9@xps> <71571fa0-f2c1-707a-235f-45ca938cc651@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap X-BeenThere: web@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK website maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 10:03:30 -0000 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: > >=20 > > > 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. > > > > > > >=20 > > > > > > > Hi Thomas, > > > > > > >=20 > > > > > > > What this change suggest? To be able to backport patches > > > > > > > from rc1? > > > > > >=20 > > > > > > Yes, it is the proposal we discussed earlier. > > > > > > We can wait one week after RC1 to get some validation > > > > > > confirmation. > > > > > > Do you agree? > > > > >=20 > > > > > This has been discussed in tech-board, what I remember the > > > > > decision was to wait > > > > > the release to backport patches into stable tree. > > >=20 > > > Any minutes? I couldn't find them > > >=20 > > > > 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. > > > >=20 > > > >=20 > > >=20 > > > I think timing of stable releases and bugfix backports to the > > > stable > > > branch are two separate items. > > >=20 > > > 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. > > >=20 > > > 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. > >=20 > > +1 - this seems to make the most sense to me.=C2=A0=C2=A0Keep the patch= es > > flowing, > > but don't label/tag it until validation.=C2=A0=C2=A0That serves an addi= tional > > function: developers know their CC's to stable are being processed. >=20 > 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. --=20 Kind regards, Luca Boccassi