search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.8k stars 6.58k forks source link

Improve documentation on backport / release process #45307

Open cfriedt opened 2 years ago

cfriedt commented 2 years ago

Is your enhancement proposal related to a problem? Please describe. While it is OK to submit PRs without an associated issue to main, all backport PRs require an associated issue. Even those automatically created by zephyrbot.

If the original PR to main does have a linked issue, or if the backport is part of a larger qualification effort with an issue, or if the backport is part of a CVE with an issue, then a new issue does not need to be created, and the existing associated issue can simply be logged in the description of the backport PR.

Otherwise, if no associated issue exists, then a new issue should be created and linked to the backport PR.

Describe the solution you'd like @dkalowsk pointed out that MCUBoot has a good document w.r.t. backporting, which is below

https://docs.zephyrproject.org/3.0.0/guides/device_mgmt/mcumgr_backporting.html

Perhaps it makes sense to generalize this document and include it in the release process documentation.

Describe alternatives you've considered Currently, the release team needs to remind PR authors to create an associated issue, and it's a very common occurrence.

Additional context

keith-zephyr commented 1 year ago

@carlescufi or @cfriedt, is this something either one of you can take on?

carlescufi commented 1 year ago

@carlescufi or @cfriedt, is this something either one of you can take on?

Sure, I will try to send something.

cfriedt commented 1 year ago

Thanks - I'm a bit behind on docs ATM.

fabiobaltieri commented 1 year ago

@cfriedt what if instead of running the "Backport Issue Check" we change it to run on the original PR instead, and fail if there's any backport tag but there's no issue associated with that one? Then as long as the tags are added before merge we'd always have an issue on the original PR, and then that's much easier to handle during backport triaging.

cfriedt commented 1 year ago

@cfriedt what if instead of running the "Backport Issue Check" we change it to run on the original PR instead, and fail if there's any backport tag but there's no issue associated with that one? Then as long as the tags are added before merge we'd always have an issue on the original PR, and then that's much easier to handle during backport triaging.

Yeah, sounds good. Also could automatically insert the existing linked issue "fixes.." in the new backport pr description

keith-zephyr commented 4 months ago

Process WG: this item also needs to be moved to the Release WG.