PX4 Dev Call: June 5th, 2019

Hi All,

Here is the Agenda for June 5th:

  • Reminder: Dev Summit: June 20-21, Zurich, Switzerland
  • Release v1.9 changelog
  • Releasev1.9.1 bugfixes
  • Next release: How to ship on time? How to reduce stalled PRs?
  • Ongoing refactoring work
  • Board deprecations before next release

More topics might be added based on the Devcall list on Github or by commenting here.


Join Zoom Meeting

Zoom Video

Join our Cloud HD Video Meeting now

Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference…

One tap mobile
+14086380968,946175205# US (San Jose)
+16468769923,946175205# US (New York)

Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 669 900 6833 US (San Jose)
Meeting ID: 946 175 205
Find your local number: https://zoom.us/u/ad94Pgv9yQ

Meeting notes:

  • Reminder: Dev Summit: June 20-21, Zurich, Switzerland
    • Schedule to be released this week
  • 1.9
  • 1.9.1
  • Test team
    • Deltaquad is crashed, convergence is the only VTOL
    • Need to close performance issues
    • Need to setup structure and automation
  • 1.10:
    • 1.9 was delayed 3 month from Jan roadmap webinar announcement
    • How to ship on time?
    • How to reduce stalled PRs?
    • We will keep half a year release cycle - okay - most users do upgrade once a year or once every two years
    • Current workload: 0.5 person working on integration, 20 ppl on features - need more bandwidth on integration/triage
    • Still shoot for 1.10 release in Sept
      • End of July, feature freeze
      • Core maintenance team block out Aug for integration
      • How to use GitHub tools (milestones?) to track - Ramon {@rroche}
    • Roadmap is general strategy/direction/priorities/focus, things get in ad-hoc
    • How to enforce feature lockdown?
      • Shall we branch off a release branch after feature freeze, then just do patches?
    • Master should always be in flying state
  • 2.0
    • When we have hardware in the market that is ethernet enabled
  • Ongoing refactoring work
    • Define workflow: squash or rebase
    • Requirements:
      • Need to be able to incrementally review.
      • Need to have every commit building and working for git bisecting.
      • Need to be able to have a history that explains the changes, gives context.
      • Downstream users need to be able to cherry-pick.
    • Possible solution by Daniel:
      • no rebasing and force pushing once reviewed
      • Review using incremental fixes
      • Once the changes are good and reviewed -> squash
    • Provide guidance to contributors?
    • Perhaps a spec for how to do a commit in master
      • Daniel create a wiki for basic process {@dagar}
    • Try out a couple of PRs and build a knowledge base around this
  • Board deprecations before next release
    • [Ran out of time to discuss - postpone to next dev-call]
1 Like