DPDK website maintenance
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>
Cc: web@dpdk.org, dev@dpdk.org, techboard@dpdk.org, bluca@debian.org,
	yliu@fridaylinux.org, christian.ehrhardt@canonical.com,
	yskoh@mellanox.com
Subject: Re: [dpdk-web] [PATCH v2] update stable releases roadmap
Date: Thu, 19 Apr 2018 10:38:10 +0100	[thread overview]
Message-ID: <bfe0d6df-7214-33b9-e941-aed120b7d969@redhat.com> (raw)
In-Reply-To: <2289123.B0I2yLRMB9@xps>

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:
>>>>> -	<p>Typically a new stable release version follows a mainline release
>>>>> -	by 1-2 weeks, depending on the test results.
>>>>> +	<p>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.

Kevin.

  reply	other threads:[~2018-04-19  9:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-09 13:36 [dpdk-web] [PATCH] " Thomas Monjalon
2018-03-09 13:44 ` Luca Boccassi
2018-03-09 13:49   ` Thomas Monjalon
2018-03-09 14:03     ` [dpdk-web] [dpdk-techboard] " Ananyev, Konstantin
2018-03-09 14:19       ` Thomas Monjalon
2018-03-09 15:24         ` Ferruh Yigit
2018-03-09 15:45           ` Thomas Monjalon
2018-03-09 17:30             ` Luca Boccassi
2018-03-09 14:30 ` [dpdk-web] " Kevin Traynor
2018-03-09 14:51   ` Thomas Monjalon
2018-03-09 15:43     ` Kevin Traynor
2018-03-22 11:03 ` Luca Boccassi
2018-03-22 11:22   ` Luca Boccassi
2018-03-22 11:25   ` Thomas Monjalon
     [not found] ` <1522937784.16877.28.camel@debian.org>
2018-04-05 14:19   ` Christian Ehrhardt
2018-04-05 14:23     ` Thomas Monjalon
2018-04-10 23:28 ` [dpdk-web] [PATCH v2] " Thomas Monjalon
2018-04-11 10:04   ` Luca Boccassi
2018-04-11 10:43   ` Christian Ehrhardt
2018-04-11 15:10   ` Kevin Traynor
2018-04-18  9:05   ` Ferruh Yigit
2018-04-18  9:14     ` Thomas Monjalon
2018-04-18 12:28       ` Ferruh Yigit
2018-04-18 13:28         ` Thomas Monjalon
2018-04-19  9:38           ` Kevin Traynor [this message]
2018-04-20 15:52             ` [dpdk-web] [dpdk-dev] " Aaron Conole
2018-04-25  8:33               ` Ferruh Yigit
2018-04-25 10:03                 ` Luca Boccassi
2018-04-30 10:47                   ` Thomas Monjalon
2018-05-01 14:16                     ` Aaron Conole
2018-05-01 15:46                       ` Kevin Traynor
2018-05-01 16:02                         ` Thomas Monjalon
2018-05-17 16:32 ` [dpdk-web] [PATCH v3] " Thomas Monjalon
2018-05-17 16:41   ` Ferruh Yigit
2018-05-17 16:59     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bfe0d6df-7214-33b9-e941-aed120b7d969@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=web@dpdk.org \
    --cc=yliu@fridaylinux.org \
    --cc=yskoh@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).