From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id 45A7028F3; Tue, 1 May 2018 17:47:03 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DEDD3EC013; Tue, 1 May 2018 15:47:01 +0000 (UTC) Received: from ktraynor.remote.csb (unknown [10.36.118.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 62DA8111DD00; Tue, 1 May 2018 15:46:59 +0000 (UTC) To: Aaron Conole , Thomas Monjalon Cc: Luca Boccassi , Ferruh Yigit , web@dpdk.org, dev@dpdk.org, techboard@dpdk.org, yliu@fridaylinux.org, christian.ehrhardt@canonical.com, yskoh@mellanox.com References: <20180309133612.19927-1-thomas@monjalon.net> <71571fa0-f2c1-707a-235f-45ca938cc651@intel.com> <1524650607.23292.6.camel@debian.org> <1906771.vQqTW93QMP@xps> From: Kevin Traynor Organization: Red Hat Message-ID: Date: Tue, 1 May 2018 16:46:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 01 May 2018 15:47:01 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 01 May 2018 15:47:01 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'ktraynor@redhat.com' RCPT:'' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 15:47:03 -0000 On 05/01/2018 03:16 PM, Aaron Conole wrote: > Thomas Monjalon writes: > >> 25/04/2018 12:03, Luca Boccassi: >>> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote: >>>> On 4/20/2018 4:52 PM, Aaron Conole wrote: >>>>> Kevin Traynor writes: >>>>>> 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: >>>>>>>>>>> -

Typically a new stable release version >>>>>>>>>>> follows a mainline release >>>>>>>>>>> - by 1-2 weeks, depending on the test results. >>>>>>>>>>> +

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. >>>>> >>>>> +1 - this seems to make the most sense to me. Keep the patches >>>>> flowing, >>>>> but don't label/tag it until validation. That serves an additional >>>>> function: developers know their CC's to stable are being processed. >>>> >>>> Are stable trees verified? >>> >>> Verification is one issue - so far, Intel and ATT have provided time >>> and resources to do some regression tests, but only at release time >>> (before tagging). And it has been a manual process. >>> It would be great if more companies would step up to help - and even >>> better if regressions could be automated (nightly job?). >>> >>> The other issue is deciding when a patch is "good to go" - until now, >>> the criteria has been "when it's merged into master". >>> So either that criteria needs to change, and another equally >>> "authoritative" is decided on, or patches should get reviewed and >>> merged in master more often and more quickly :-P >>> >>> We also have not been looking directly at the the various -next trees, >>> as things are more "in-flux" there and could be reverted, or clash with >>> changes from other trees - hence why we merge from master. >> >> Yes, backporting from master is definitely the right thing to do. >> Backporting more regularly would be also an improvement. >> There will be always the question of the bug-free ideal in stable >> branches. I agree we need more help to validate the stable branches. >> But realistically, it will never be perfect. >> >> 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? >> That's why it's important to wait a validation period (happening after >> each release candidate) before tagging a stable release. >> So, if we are aware of a regression in the master branch, which has been >> backported, we can wait few more days to fix it. >> The last thing we need to consider before tagging, is the validation of >> the stable release itself. Are we able to run some non-regression tests >> on the stable branch if it is ready few days after a RC1?