There was some confusion about how to update the schedule. I'm sure Aoife gave Jef the lecture, but just in case, here's the cliff notes.

There's an awful internal Red Hat thing (well, it's a third party SaaS thing I think) called smartsheet which is actually the 'canonical' schedule data source. The schedule is supposed to be created and modified there. Then it's exported from that tool as XML (sorry, I have mindbleached away the details on exactly how to do this) and the XML file committed to this repo. Then you have to run make publish from the appropriate directory in this repo to actually publish the modified schedule; for that to work you have to change the LOGIN line in common/Makefile.common in your checkout to be your username instead of amoloney , and your user has to have rights to rsync things to fedorapeople.org:/project/schedule .

You can skip the smartsheet step and modify the XML in this repo directly, but there are risks. Obviously, if anyone then goes back to smartsheet for further edits, they will blow away your downstream changes unless they know about them and 'backport' them into smartsheet. Also, the schedule is surprisingly complex and interdependent; there are overarching 'events' and almost every date isn't absolute, it's relative (they're all defined as 'X days after base event Y' or similar, with just a very few absolute base events). If you just go in and edit single dates this can get out of sync and weird stuff can happen. Regardless, after changes land in the XML files here the manual publishing step has to be done for the actual published schedule to see changes.

See also: https://docs.fedoraproject.org/en-US/program_management/pgm_guide/schedule/

Okay so this is more complicated... and gets into sheets logic..

The item in sheets that is being exported and published in the HTML schedule is actually a roll up of several 'hidden' subtasks which include
the tooling subtask that as a 01-07 date followed by the RPM mass rebuild subtask.

changing the 'hidden' "mass rebuild start" subtask's date to 01-14 doesn't impact the published schedule for "RPM: Mass Rebuild" because the subtask "Major Tool Changes Landed" still has the correct 01-07 date.

So I'm not sure what the intention here is.
why are the subtasks hidden?
why is the tool changes landed a subtask?

I can't answer those questions. But assuming that the "tool changes landed" subtask has the correct date and is suppose to be a subtask of "RPM: Mass Rebuild" the HTML schedule as published right now is correct as intended.

Got this sorted out.

The Major Tools Changes Landed subtask is new this cycle and its placement is the root cause of the confusion here.

I've reparented the Major Tools Changes landed task outside of the Mass Rebuild parent task dates should read as expected now.

This has been published.