DPDK website maintenance
 help / color / mirror / Atom feed
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
Subject: Re: [dpdk-web] [dpdk-dev] [PATCH v2] update stable releases roadmap
Date: Tue, 01 May 2018 18:02:00 +0200	[thread overview]
Message-ID: <10920490.snMLn0g3xm@xps> (raw)
In-Reply-To: <fa381e80-d86f-3277-bf8c-3e429746fd72@redhat.com>

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.

  reply	other threads:[~2018-05-01 16:02 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
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 [this message]
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=10920490.snMLn0g3xm@xps \
    --to=thomas@monjalon.net \
    --cc=aconole@redhat.com \
    --cc=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=techboard@dpdk.org \
    --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).