From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <luca.boccassi@gmail.com>
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com
 [209.85.221.51]) by dpdk.org (Postfix) with ESMTP id 456724C94
 for <dev@dpdk.org>; Tue, 12 Mar 2019 21:46:47 +0100 (CET)
Received: by mail-wr1-f51.google.com with SMTP id o9so4181940wrv.9
 for <dev@dpdk.org>; Tue, 12 Mar 2019 13:46:47 -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:user-agent:mime-version;
 bh=mXWlt/s+1/ZFxvWKyjRFo77Sy0QXK6Zg5qYDIoiEDO4=;
 b=oFb7H5WdWPnC7I/KRWSYX7DJwY7RVMgfRKnyTMRB4uJn9sAAoby3f+pSv8qOPTk1wl
 uG5BfOnX75AOVyvddc25DHqX+meFiePTCoSlyw7xi5+I01Jz+AmRKQTB98zmsVkOt12A
 kmQtzQhdpeM/oahYFIymizrlHi57TtxSoYvHabMBTXavKa/DMsLmRGF32y4jqdAWUG32
 EgWHFgYm4Z1P3bZZDvyrNKmbf+F/0AE/ta2EP7CCf5CDDnmMbOYREijfgLZSKNhpppNB
 EGx6GXlwUlLPq5CgUfYhWrqwhJheiJBNoFGwl3hHsA2lsEP7rakop+V1MzP5P60zenOx
 JU6A==
X-Gm-Message-State: APjAAAVolNpFb8n7RMSQ8k70WIefXr2hcjqNE5VfQAiqvTbJnZ4wdU9/
 WEblB0sgaiDZtR9rW8rk6A8=
X-Google-Smtp-Source: APXvYqwRcQlsv/ly70+XUv9XbyV2dIAsu69nXNwOrE/kx6epbw61T3hrkqHHE5SOUGR7wvLBfMIiDQ==
X-Received: by 2002:a5d:4110:: with SMTP id l16mr5578516wrp.129.1552423606715; 
 Tue, 12 Mar 2019 13:46:46 -0700 (PDT)
Received: from localhost ([2a01:4b00:f419:6f00:b00c:66c8:99df:336])
 by smtp.gmail.com with ESMTPSA id 93sm20353272wrh.15.2019.03.12.13.46.45
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Tue, 12 Mar 2019 13:46:45 -0700 (PDT)
Message-ID: <834f085314caae4091cfc02c5c904a6efaed3141.camel@debian.org>
From: Luca Boccassi <bluca@debian.org>
To: Kevin Traynor <ktraynor@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Yongseok Koh <yskoh@mellanox.com>, Thomas Monjalon
 <thomas@monjalon.net>,  Ferruh Yigit <ferruh.yigit@intel.com>, John
 McNamara <john.mcnamara@intel.com>, Aaron Conole <aconole@redhat.com>,
 "Walker, Benjamin" <benjamin.walker@intel.com>, Jay Rolette
 <rolette@infinite.io>
Date: Tue, 12 Mar 2019 20:46:45 +0000
In-Reply-To: <0989b56a-f480-416c-e0a7-3e562c9b990b@redhat.com>
References: <0989b56a-f480-416c-e0a7-3e562c9b990b@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.30.5-1 
MIME-Version: 1.0
Subject: Re: [dpdk-dev] DPDK short term stable maintenance
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://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 20:46:47 -0000

On Tue, 2019-03-12 at 19:12 +0000, Kevin Traynor wrote:
> Hi All,
>=20
> This is about short term stable maintenance, ~3 months based on
> n.02/05/08 DPDK. It is **not** referring/impacting DPDK LTS,
> maintained
> for ~2 years based on n.11 DPDK.
>=20
> The effort and usefulness of short term stable maintenance was raised
> previously and in the last DPDK Release meeting [1], so sending mail
> to
> kick off discussion here...
>=20
> Currently DPDK 19.02 stable branch has no maintainer and it has been
> difficult to get the companies to validate DPDK 18.08.1 RC. There
> seems
> to be a lack of appetite in the community for short term stables, or
> at
> least for all of them, and hence giving resources for helping them.
>=20
> It could be that users are either moving from latest bleeding edge
> master release to the next, or settling on DPDK LTS for an extended
> period of time - I'm just speculating, but IMHO that would not be a
> bad
> thing.
>=20
> So what to do with short term stables? Some choices could be:
>=20
> - continue with short term stables for n.02/05/08
> - ad-hoc support for short term stables where community have an
> interest
> in a particular one
> - have a maintainer to backport fixes on a public branch, but have no
> releases, or have unvalidated/best effort validated releases
> - no short term stable branches/releases
>=20
> Probably there's other ideas too. Obviously most of the above would
> need
> resources from the community to proceed. One advantage of not having
> short term stables is that there might be more resources available
> for
> maintenance/validation of master and LTS DPDK releases.
>=20
> Thoughts?
>=20
> thanks,
> Kevin.
>=20
> [1] https://mails.dpdk.org/archives/dev/2019-March/126006.html

Hi,

Thanks for starting the discussion.

My 2c is that, unless someone steps up not only for the maintainer role
but also for the validation effort, we should cancel the short term
releases.

--=20
Kind regards,
Luca Boccassi