From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 9B055DED;
 Tue,  1 May 2018 18:02:03 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 3D9F222087;
 Tue,  1 May 2018 12:02:03 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Tue, 01 May 2018 12:02:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc; s=mesmtp; bh=4lE8bCg7rp3qTX2fB8yRdJK2vq
 XaMSAmY2JoYHhNRNU=; b=MWmRf8zuHkWX8IC7xfnZCbVckVYf+CGEqG64eaNiiL
 XwjLSD4gQHIFbEZB51B9LxGjnmwA+4kcGxlKiNOSFL6wxWYcoG6v9bHXKI6bMN+i
 p+83rUpm+JSsrVhHlRO92eGCjytCHACfqf9+C03P/nIeRcWQ7TptzJ3LCoylTW09
 A=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4lE8bC
 g7rp3qTX2fB8yRdJK2vqXaMSAmY2JoYHhNRNU=; b=bcKW6MIUMaVoAzx/TXlHi6
 c4TOgUpkv60oyNzk97BoSJkU5ZjD0fwRLn8RXZCFPJw+UVxngbXKz78AK+a4EPnS
 Y8Ebmh4SZbH2RyZkd8m5JCAPBNjBSs1MlXyBWUxwCPGszrAPEpIoTW7DgLkp+l2J
 Oqz0N/nFgmI1payOotHkyfo2zg1yGt1SbQ+IvCv+cM5+IZQn468mVCzPIi3eJ/8M
 UN+I2jNjwtrTHxIcYXIjq8LyEWOkm9jNQEChwuQaebbdpsdRKJvbMG4jXZbqCTal
 4mJvBuHemzQ/xK4uKYdVcZUXEtwuXxIA1QNy70VlL7g+1PZ1Pp2NAJoht5lhl/+g
 ==
X-ME-Sender: <xms:e4_oWrm6x4ndgXEGZCQtUkZ1JVsjXXTZmh4pVPuk5j1u5CGjeINz8g>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id A2F33E498E;
 Tue,  1 May 2018 12:02:01 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Kevin Traynor <ktraynor@redhat.com>
Cc: Aaron Conole <aconole@redhat.com>, Luca Boccassi <bluca@debian.org>,
 Ferruh Yigit <ferruh.yigit@intel.com>, web@dpdk.org, dev@dpdk.org,
 techboard@dpdk.org, yliu@fridaylinux.org, christian.ehrhardt@canonical.com,
 yskoh@mellanox.com
Date: Tue, 01 May 2018 18:02:00 +0200
Message-ID: <10920490.snMLn0g3xm@xps>
In-Reply-To: <fa381e80-d86f-3277-bf8c-3e429746fd72@redhat.com>
References: <20180309133612.19927-1-thomas@monjalon.net>
 <f7tvac7foln.fsf@dhcp-25.97.bos.redhat.com>
 <fa381e80-d86f-3277-bf8c-3e429746fd72@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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 <web.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/web>,
 <mailto:web-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/web/>
List-Post: <mailto:web@dpdk.org>
List-Help: <mailto:web-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/web>,
 <mailto:web-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 01 May 2018 16:02:04 -0000

01/05/2018 17:46, Kevin Traynor:
> On 05/01/2018 03:16 PM, Aaron Conole wrote:
> > Thomas Monjalon <thomas@monjalon.net> writes:
> >> 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").
> > 
> 
> I agree and I think it's the best way. However, it also requires
> semi-frequent pull request merging into the master branch for this to
> work. Otherwise there is still delay, just earlier in the process.
> 
> Not sure if there is a written/un-written workflow for when the next-*
> branches merge into master at the moment?

We try to have more pulls before RC1.
It is not formal yet.