Re: [dpdk-dev] [dpdk-web] [PATCH v2] update stable releases roadmap

[Kevin Traynor <ktraynor@redhat.com>]

On 05/01/2018 03:16 PM, Aaron Conole wrote:
> Thomas Monjalon <thomas@monjalon.net> 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 <ktraynor@redhat.com> 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:
>>>>>>>>>>> -	<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.
>>>>>
>>>>> +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?