OTP Summit
184 views
Skip to first unread message
Andrew Byrd
Jul 19, 2018, 6:20:02 AM7/19/18
to OpenTripPlanner Developers
Hello OTP developers,
About one month ago (on June 12-14), we held the first “International OTP Summit” in Boston at the offices of Cambridge Systematics. Contributors flew in from across North America and Europe to represent organizations maintaining and deploying OTP. We were successful in achieving alignment on some critical technical and governance issues. Here are some of the major results:
1. The OTP Project Leadership Committee (PLC) continues to move toward a model of one member per organization, with a larger number of organizations represented. A current list of committee members, as well as technical staff authorized to approve pull requests can be found in the governance section of the OTP documentation.
2. In the interest of improving resource consumption and response times as well as long-term maintainability, the newly enlarged committee approved a concrete plan to update major parts of the transit routing core over the next six months, a path already approved in principle by the PLC last year. Concretely, this means reviving work on a RAPTOR-based router.
3. In order to allow merging several outstanding branches based on the current transit router without impeding work on the new router, we will create two development branches of OTP. After the next 1.x release (which should occur in the next few days) pre-existing work will be merged into a 1.x branch, and a new 2.x branch will be created to house the new transit routing work.
4. We will aim for minimal disruption of the OTP trip planning API in the new OTP 2.x. In the interest of long-term maintainability we will research which options and endpoints are used the most and remove unmaintained or infrequently used elements, but without breaking backward compatibility for the endpoints and options that remain.
5. Code review procedures have been reinforced, with the goal that new non-bugfix code should correspond to roadmap features approved by the committee.
6. Several organizations have committed resources (full time software developers) to achieving these goals. If any other organizations have professional software development staff working on OTP transit routing improvements, please contact us so we can better coordinate our changes.
Let us know if you have any questions!
-Andrew
About one month ago (on June 12-14), we held the first “International OTP Summit” in Boston at the offices of Cambridge Systematics. Contributors flew in from across North America and Europe to represent organizations maintaining and deploying OTP. We were successful in achieving alignment on some critical technical and governance issues. Here are some of the major results:
1. The OTP Project Leadership Committee (PLC) continues to move toward a model of one member per organization, with a larger number of organizations represented. A current list of committee members, as well as technical staff authorized to approve pull requests can be found in the governance section of the OTP documentation.
2. In the interest of improving resource consumption and response times as well as long-term maintainability, the newly enlarged committee approved a concrete plan to update major parts of the transit routing core over the next six months, a path already approved in principle by the PLC last year. Concretely, this means reviving work on a RAPTOR-based router.
3. In order to allow merging several outstanding branches based on the current transit router without impeding work on the new router, we will create two development branches of OTP. After the next 1.x release (which should occur in the next few days) pre-existing work will be merged into a 1.x branch, and a new 2.x branch will be created to house the new transit routing work.
4. We will aim for minimal disruption of the OTP trip planning API in the new OTP 2.x. In the interest of long-term maintainability we will research which options and endpoints are used the most and remove unmaintained or infrequently used elements, but without breaking backward compatibility for the endpoints and options that remain.
5. Code review procedures have been reinforced, with the goal that new non-bugfix code should correspond to roadmap features approved by the committee.
6. Several organizations have committed resources (full time software developers) to achieving these goals. If any other organizations have professional software development staff working on OTP transit routing improvements, please contact us so we can better coordinate our changes.
Let us know if you have any questions!
-Andrew
Reply all
Reply to author
Forward
0 new messages