From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [dpdk-web] [PATCH v2] update stable releases roadmap Date: Tue, 01 May 2018 18:02:00 +0200 Message-ID: <10920490.snMLn0g3xm@xps> References: <20180309133612.19927-1-thomas@monjalon.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Aaron Conole , Luca Boccassi , Ferruh Yigit , web@dpdk.org, dev@dpdk.org, techboard@dpdk.org, yliu@fridaylinux.org, christian.ehrhardt@canonical.com, yskoh@mellanox.com To: Kevin Traynor Return-path: In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 01/05/2018 17:46, Kevin Traynor: > On 05/01/2018 03:16 PM, Aaron Conole wrote: > > Thomas Monjalon 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.