`u_milestone` `-f` flag unwantedly adds a value ("meeting") to an empty `type` field

[Nicholas G. Asker]

u_milestone updater assigns a value to the type field (e.g., "meeting") when the -f flag is passed to mark something as finished, if the milestone doesn't already have a value in type. This happens commonly with kickoff meetings, which are NOT given a value of "meeting" when created. But when someone runs the milestone updater to finish the kickoff meeting, it assigns the value "meeting" to the empty type field (along with properly marking the milestone as finished and adding date information). This causes CI to fail.

Specifically, it fails CI because it is not passing regolith validate. It is because kickoff doesn't have a type in the schema because it is always a meeting (and the updater is giving it a type).

[Nicholas G. Asker]

I think there's certainly something wonky going on with the -f code that's causing the errant behavior and needs to be looked at.

Independently, I am wondering if it would make sense to add "meeting" as the default type for kickoff in the schema.

[Simon Billinge]

I think there's certainly something wonky going on with the -f code that's causing the errant behavior and needs to be looked at.

Independently, I am wondering if it would make sense to add "meeting" as the default type for kickoff in the schema.

This would be the best solution for sure. It is kind of annoying in retrospect that this "special" milestone is incompatible with the general milestone.... Let's fix this by adding type: as required to the schema for kickoff.... Will have to change the exemplars then and have the prum builders pass, but also to update every prum in our existing database. If we make it not required we won't have to do that last step but we would be only half way to making it compatible.