On 05/01/2018 03:16 PM, Aaron Conole wrote: > Thomas Monjalon <tho...@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 <ktray...@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?
