PX4-user_guide icon indicating copy to clipboard operation
PX4-user_guide copied to clipboard

Published 20 hours ago • verified publisher icon PX4

PX4 Release procedure

Open junwoo091400 opened this issue 2 years ago • 18 comments

About

This adds the initial PX4 Release procedure documentation, as discussed in today's Maintainers Call.

PX4 didn't have a set and stone release cycle management, and this is a first step towards having that & more structure.

Note to maintainers

Please review this carefully & provide your feedback on how our release procedure should be. Your review matters!

junwoo091400 avatar Mar 07 '23 18:03 junwoo091400

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-march-07-2023/31059/2

swimmingseeds avatar Mar 07 '23 18:03 swimmingseeds

Just a note: Thanks everyone for providing feedback either directly/indirectly, it is super nice to have different opinions gathered :raised_hands:

junwoo091400 avatar Mar 08 '23 20:03 junwoo091400

If I may, maybe it's implicit, but in the release procedure I'd add a "doc synchronization" phase, such that when the point release is performed, the documentation is ready.

beniaminopozzan avatar Mar 09 '23 01:03 beniaminopozzan

If I may, maybe it's implicit, but in the release procedure I'd add a "doc synchronization" phase, such that when the point release is performed, the documentation is ready.

This is implied but not well followed. It should be explicit.

Of course it should be done when the PR is effectively stable, ideally before it even merges.

hamishwillee avatar Mar 09 '23 05:03 hamishwillee

@junwoo091400 As a manufacturer, the most important thing for us is hardware support. Having stable firmware release in timely manner is very important to us because there are always things changing in the Main branch.

So it would be great for us if we can get patches release more often and receive timely update on the timeline of future patches and point releases.

vincentpoont2 avatar Mar 14 '23 06:03 vincentpoont2

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-march-14-2023/31154/1

swimmingseeds avatar Mar 14 '23 14:03 swimmingseeds

I'd add a "doc synchronization" phase

Regarding having docs in sync. If it was up to me the docs would live in PX4 tree and that way kept in sync. And a new features would be merged at the same time as the docs about it.

julianoes avatar Mar 14 '23 20:03 julianoes

I'd add a "doc synchronization" phase

Regarding having docs in sync. If it was up to me the docs would live in PX4 tree and that way kept in sync. And a new features would be merged at the same time as the docs about it.

My experience is that the location of docs-source makes very little difference. What makes a difference is developers who understand that their work is pointless if they don't do documentation.

hamishwillee avatar Mar 15 '23 02:03 hamishwillee

My experience is that the location of docs-source makes very little difference. What makes a difference is developers who understand that their work is pointless if they don't do documentation.

Yes but it's a way to block a PR because of docs missing.

julianoes avatar Mar 15 '23 22:03 julianoes

My experience is that the location of docs-source makes very little difference. What makes a difference is developers who understand that their work is pointless if they don't do documentation.

Yes but it's a way to block a PR because of docs missing.

I strongly agree, the majority of the trivial breaks (refactoring and other churn) could have been caught in the same sweep.

The other angle that periodically surprises me is when we have reasonably good documentation in place for random things that quite frankly are unsupported experimental features with no automated testing or active maintainers.

Anyway, it doesn't even need to be everything, but things that map to specific modules, drivers, boards, etc would be fantastic to capture centrally and update atomically moving forward.

dagar avatar Mar 15 '23 23:03 dagar

We should take this offline since it isn't going to happen in a timeline around this PR, if at all.

The cost of this would be quite high for a bunch of very unconvincing arguments. Certainly nothing there showing it is the best use of my time to move the docs. Note that I wouldn't be unhappy if they were already in-source - it would be satisfying. But I'm pretty sure nothing would be significantly different.

I am very interested in docs automation and whatever you were talking about in your last point @dagar . If that stuff is useful and requires docs source alongside PX4 source then there might be justification.

Yes but it's a way to block a PR because of docs missing.

This would only be true if the PR would not be able to build if the docs were not present. Since there is nothing to stop PRs being accepted without docs, and that would not change even if docs lived in the source tree, this is a flawed supporting argument.

I strongly agree, the majority of the trivial breaks (refactoring and other churn) could have been caught in the same sweep.

I don't care about the trivial stuff. I can spot a lot of that via the obviously broken links.

I'm worried about the massive restructures such as simulation, XRCE-DDS which went in with zero thinking about what might be affected in docs. How would these be improved by having the docs in-source?

The other angle that periodically surprises me is when we have reasonably good documentation in place for random things that quite frankly are unsupported experimental features with no automated testing or active maintainers.

That's because those developers were willing to document what they did. Its a fair point though - how did the PR get through without automated testing and active maintainers? How can we identify these parts in the docs and prioritize better?

Anyway, it doesn't even need to be everything, but things that map to specific modules, drivers, boards, etc would be fantastic to capture centrally and update atomically moving forward.

I don't know what you mean by this ^^^^. I'm interested though. Concrete examples?

hamishwillee avatar Mar 16 '23 02:03 hamishwillee

We should take this offline since it isn't going to happen in a timeline around this PR, if at all.

Just FYI, we discussed during maintainers meeting and will be organizing a documentation meeting to discuss the details (for the upcoming 1.14 release docs sync, and other topics): https://discuss.px4.io/t/px4-maintainers-call-march-21-2023/31237#px4-documentation-synchronization-discussion-6

junwoo091400 avatar Mar 21 '23 17:03 junwoo091400

No flaws found

github-actions[bot] avatar May 10 '23 05:05 github-actions[bot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-may-30-2023/32372/1

DronecodeBot avatar May 30 '23 15:05 DronecodeBot

So it would be great for us if we can get patches release more often and receive timely update on the timeline of future patches and point releases.

Related to this, discussing with Ramon yesterday also about how the v1.14 release has been dragging along for a while, I think that following changes to the procedure would be beneficial:

  1. Backport PRs should only be created against the past releases (e.g. now, only v1.12 or older backport PRs should be created)
  2. Backport to the current release in process shouldn't be done by authors of each PR: This requires too much effort on developer's side to create 2 separate PRs
  3. The backport to current release should be done via a single big PR (e.g. this: https://github.com/ArduPilot/ardupilot/pull/23958), where the commits from the PRs compiled in the project board (to be backported) gets cherry picked by the release maintainer all at once
  4. Beta release should be done every week, to keep the pace (currently we have been dragging for 3+ months, creating bad user experience)
  5. In accordance with single backport PR per beta release (point 3 above), the project board should keep track of the PRs that should be included in the new beta release, by patch version

junwoo091400 avatar Jul 03 '23 22:07 junwoo091400

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-july-04-2023/32943/1

DronecodeBot avatar Jul 03 '23 22:07 DronecodeBot

Re https://github.com/PX4/PX4-user_guide/pull/2331#issuecomment-1619210692

  1. You probably need to start even earlier in the process, with criteria for inclusion in a beta + the previous release. The past release should get only critical bug fixes. Nothing else. Ever. The cost of retesting is otherwise too high and you never progress.
  2. Yes, beta should be updated regularly.
  3. If you ever want to make a release then you need a plan, and you need to be prepared to stop. Do we have a plan in which PX4 v1.14 will ever release?

hamishwillee avatar Jul 04 '23 23:07 hamishwillee

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-july-11-2023/33057/1

DronecodeBot avatar Jul 11 '23 14:07 DronecodeBot