1.12 development timeline

Autoware
1

This thread is to plan the work to be done in the first couple of weeks of the 1.12 release cycle.

Because we are planning some significant changes to our development processes and environment for 1.12, we need to decide what will be done when to prevent problems such as PRs being made while we are moving packages around.

This is the list of things that need to be done, not necessarily in order. Please comment if you think I have missed one.

  • Move the Autoware reposiory to the autowarefoundation organisation
  • Create new repositories according to the repository discussion
  • Move packages to new repositories
  • Move packages to new layout
  • Change permissions on repository
  • Add .repos file and switch to using vcs for installation
  • Decided on features to include in 1.12 and add them to the milestone
  • Clean up the branches to match the new branching model
  • Fixing CI to work with the new repository layout
  • Fix the docker images

Here is my proposal for when we do each thing that needs to be done. Please comment and I will update the table as we discuss.

Day Things to do
Thursday, March 21 Release 1.11
Start of no-new-PRs period
Friday, March 22 Public holiday
Saturday, March 23
Sunday, March 24 Sleep
Monday, March 25 Move the repository to the new organisation
Create new repositories for Autoware
Change permissions on repositories
Create autoware.repos
Change installation instructions to use vcs
Remove develop branch; master becomes the main branch
Start collecting features for 1.12
Tuesday, March 26 Start fixing CI and docker
Clean up other branches as possible
Wednesday, March 27
Thursday, March 28
Friday, March 29
Saturday, March 30
Sunday, March 31 Sleep more
Monday, April 1 Freeze list of features targeted for 1.12 (except for justified exceptions on a case-by-case basis)
Contributors start working on their own fork
Open for PRs again
Tuesday, April 2
Wednesday, April 3
Some time during the above Fix CI to match new repositories
After Move packages one at a time to new repositories (timing of each based on PRs for that package)
Move code between packages to improve package layout

Ultimately, this work is going to be disruptive. My hope is that by doing it as soon as possible and in one chunk we can minimise that disruption.

I think the package reorganisation (into repositories, and code into packages) can be done over
time. We can do each package individually once we shift to vcs so there is no need to rush them
all in at once. This gives us some flexibility to work around pull requests.

An open question is what to do with existing PRs that won’t be merged for 1.11. Do we ask the
person doing it to move to a fork and make a new PR now?

Update 2019/03/12
We can move the repository to a new organisation and keep all the issues, watchers, stars, etc. I have updated the schedule.

Update 2019/03/15
Delayed everything a week due to the delay in releasing 1.11.

2

Here’s my proposal for how we handle cleaning up the branches as part of changing the branching model.

  1. If the branch is merged, delete it.
  2. If the branch is for an unmerged pull request that is actively being developed:
    • Have the original submitter fork the repository and make a new PR from that branch in the fork.
    • Delete the branch in the upstream.
    • Reference the original PR from the new one so discussion is linked.
    • Close the original PR.
  3. If the PR is for an unmerged PR that has not seen activity for some time:
    • Close the PR.
    • Ask the submitter to make a fork and do as for active PRs, above.
    • Schedule the branch for deletion in one month.
    • If the submitter is unresponsive or unwilling to continue the work, try to find someone else to take over.
  4. If the branch is not linked to a PR but is actively being developed:
    • Ask the person who is working on it to fork and work on the branch in their fork, then do a PR as per the new development process.
    • Delete the branch once the fork has been created.
  5. If the branch is not linked to a PR and is not actively being developed, delete it. If we really want it the history will still be there so we can resurrect it later.
    • Unless someone wants to take over the work, in which case they must make a fork.

Please provide comments or alternative proposals!

1 Like
3

We have an update on the GitHub organisation name. Unfortunately, the person who registered it apparently is using it, just not in public so it appears to be unused.

We need to choose a new name. Options include:

  • AutowareOrg (possibly taken, perhaps by @kfunaoka)
  • AutowareAI (possibly taken, perhaps by @kfunaoka)
  • AutowareAuto (possibly taken, perhaps by @kfunaoka)
  • AutowareFoundation (grabbed by me)
  • NotApollo

I’d like to choose one by the end of this week so I can get moving on the above tasks. Please vote for one of the above or make a new suggestion!

1 Like
4

AutowareAI +1
This would follow the same pattern as AutowareAuto.

5

This organisation will ultimately host both Autoware.AI and Autoware.Auto.

6

AutowareFoundation +1.

We can finally have AI and Auto in one organisation(GitHub) or group(GitLab).

3 Likes
7

In that case
AutowareFoundation

1 Like
8

Also voting for AutowareFoundation so that it ties with the header in https://www.autoware.org/

2 Likes
9

The release of 1.11 has been delayed a week to March the 21st. So as not to get in the way of that release process, I’m delaying the work on moving repositories, cleaning permissions, etc. a week as well.

I will use the extra time to clean up the existing issues, since most of that does not have to wait for 1.11.

10

Merge features from these branches into the develop:

  1. https://github.com/CPFL/Autoware/tree/feature/pacmod_apex
  2. https://github.com/CPFL/Autoware/tree/experimental/peoria_internal_test or https://github.com/CPFL/Autoware/tree/experimental/peoria

@aohsato or @shinpei0208 can you list more?

11

experimental/peoria was created for our local testing but some merged branches are probably not needed to merge to master, e.g. feature/deadreckoner. You can easily divide these into some feature branches, actually peoria has only merge commits (peoria_internal_test has 1 direct commit for local change).

These branches were merged to experimental/peoria, we can pick from here for next release.

  • New features
    • feature/rebuild_decision_maker
    • feature/point_pillars
    • feature/deadreckoner
  • Update of current feautures
    • feature/signal_pole_grouping
    • fix/rtm_calibration_publisher
    • feature/fix_motion_predictor
    • feature/velocity_set_with_prediction
    • feature/velocity_interpolation
  • For UI
    • feature/update_autoware_launcher
    • feature/point_pillar_launcher_plugin
    • feature/decision_maker_launcher_plugin
    • feature/autoware_launcher_plugins

I additionally want to merge feature/improve_ymc_interface and some features to v.1.12. Is the deadline issues until April 1?

12

The April 1 deadline is for deciding the roadmap. The deadline for actually merging the features will be later; probably mid to late May. This will be decided next week.

1 Like
13

I’d be willing to help out here. Is there a ticket detailing what exactly would like to be done?

14

Not yet; I still don’t know enough about it myself. But basically what we need to do is make the existing CI work with the new repository locations. It will probably need to wait a week until we sort out the repositories and set up a .repos file.

I think @sgermanserrano and @esteve are probably the people to provide information on what needs to be done.

15

Here’s a progress update:

  • The organisation has been created.
  • The people with write permissions to the repository have been scaled right back.
  • The new repositories have been created.
  • An autoware.repos file has been created (PR).
  • The existing pull requests are being pruned. About half have been merged or closed. The remaining ones are either valid or the original creator is non-responsive.
  • The develop branch cannot be removed until any PRs against it are closed or merged. It will be removed when that happens, so don’t use it anymore.
  • Features for 1.12 are being gathered in the 1.12 milestone.
1 Like