Hi All,

I am working on enable NXP EDMA drivers to Zephyr DMA framework, and I have two DMA API changes need to discussion.

1.    https://github.com/zephyrproject-rtos/zephyr/pull/28895

in this PR, I add chain_link by using the dest_chaining_en(Major) and source_chaining_en(minor).
2. https://github.com/zephyrproject-rtos/zephyr/pull/27737
in this PR, https://github.com/zephyrproject-rtos/zephyr/pull/27737/commits/25e19f5b4e4ef07b1598104a02c4722386f2f17b two helper APIs is added
dma_api_request_channel request_channel;
dma_api_release_channel release_channel;
the two APIs are for DMA engine which is capable to dynamically allocate its channels to different DMA requests. and a filter is also added in case of special DMA channel features.

Slack topic discussion is here

Can this topic be scheduled in next API meeting? Thanks.

Regards,

Hake

Hi,

There is nothing absurd about discussing this topic at any time.

This is a major release with significant impact, and we should be able to make the assessment and have a judgment call if we are ready to release something or not, at any time. Ideally, progress should have been tracked and assessed earlier, I agree, but better late than never.

Unfortunately, you are just looking at one aspect of what LTS is, which happens to be in the name (LTS) and disregarding everything else.

The project has defined what LTS is and its significance, both in the charter and in discussions leading to the first LTS which set the ground for future LTS releases. The “old slides” are what the project agreed on and are not some random opinions by someone. The following is how LTS was defined:

• Long term support
• Stable and mature APIs
• Expanded Testing and Coverage
• Certifiable: LTS codebase will be the basis for the auditable branch

“Long Term Support” is not a release criterion, it is a release characteristic that can’t be accomplished or done if you do not have the following 2 criteria points: stable and mature APIs and expanded testing and coverage.

The last point about being certifiable derives from mature APIs and expanded testing with additional items that overall serve the quality and maturity of the project and sets the ground for additional work that can be done on top of an LTS release which is part of the project charter, which I would not disregard so easily.

Right now, 2 options are being considered:

1. Release 2.6 as LTS: With some shortfalls and with risk of not being usable for certification, next opportunity will be LTS 3 in 2 years. This will be another release with long term support. We need to switch development to LTS mode immediately and shift some of the priorities and pull in the feature freeze milestones and it will require us to delay some new features and API changes until after 2.6.
2. Delay LTS to 2.7 (End of September): This will give us additional time to close on some of the additional criteria beside being supported for a long term. Get everything we need for LTS by 2.6 and focus on stabilisation in 2.7 timeframe.

There might be other options here, but ideally, we should avoid having multiple variants of zephyr that are maintained for a long period of time. There is a lot of overhead associated with that.

Anas

As an active Zephyr contributor for over two years, speaking as an self-employed contractor and not for anybody that funds some of those contributions, I would like to provide a perspective on the LTS issue.

LTS1 (1.14.0) was released 2019-04-06.  The published date for LTS2 release is 2021-05-28.  That LTS2 was expected by the middle of this year cannot be considered a surprise.

I find it absurd that we are now, three months before that release, discussing whether it will occur on schedule, and what it will be.

Regardless of what the Zephyr charter or old slide decks contain, the term LTS is widely understood to mean "long term support": a reasonably well-tested release with a commitment to provide over several years scheduled updates that fix important security or functional problems. Companies plan product releases with the expectation that the frameworks they're depending on will stabilize and be available in a supported release at roughly the promised date.

I recognize that many features that Zephyr member companies had intended to be in LTS2 aren't ready.  But that's a problem for those companies, and shouldn't be made into one for other Zephyr stakeholders.

A decision to not release 2.6 this spring/summer as LTS2 and support it as promised would abrogate the agreement Zephyr has with its users, particularly affecting smaller companies and individuals who are not project members, don't have any vote in this question, and may not even be aware that it's being discussed.

My recommendation is: Proceed with 2.6 LTS2 as promised.  Direct short-term planning effort toward scaling down and documenting expectations for this release, and to addressing significant known shortfalls in existing features if that can be done without breaking things.  Announce soon exactly what will be in 2.6, and release it on schedule as an LTS.

Then go back and figure out what went wrong and how to address the process gaps that led to this situation.

Peter