 This is the schedule training for the Fedora program management team and this training video is going to be a little bit different because some of the tools that generate the schedule are restricted to Red Hat employees, so it's not going to be something where people can directly participate as much as other parts of the project but I do want to make sure that you know the schedule is understood, you know, some of the philosophy behind it and how the tooling works just so that you have an understanding when you do things that interact with the schedule. As you probably know Fedora Linux releases on a six-month schedule with targets towards the end of April and the end of October and this is a very predictable schedule. We've been following it sort of by default for a long time and a couple of releases ago I went to Fesco and said what if we just accepted this as our schedule in perpetuity and so now basically the schedule always exists this way unless we actively change it where previously each release I had gone to Fesco and said would you please approve this new schedule and they always said yep, and it was basically the same as the last one. One of the things we do in the schedule is we have multiple release targets and that's not just the the beta miles delivery and the final release delivery but we actually have multiple targets for each of those dates. The idea being we have an early target date, which is what Fedora contributors should really be aiming for and then we have a target date number one, which is essentially the the real one that we usually hit and that's what the public and Fedora Linux users should be expecting. The idea there is if we set a little bit of an early deadline for ourself we're not as likely to miss the actual deadline. It's sort of like when you set a couple of alarms, five minutes before you're actually supposed to wake up just to help make sure you're awake for your actual alarm in the morning. I'm going to jump into the tool we use to actually build the schedule now. It's called Smartsheet. It's a software as a service that Red Hat pays for for internal product development. And so that's what Fedora uses as well in order to be able to link that with Red Hat development. You won't be able to actually directly access or interact with this but I want you to sort of see the way we build the schedule. Many years ago we used the tool called TaskJuggler, which is written in Ruby and TaskJuggler version three doesn't have a GUI at all. So basically writing your task by hand and then using TaskJuggler to generate Gantt charts and websites and things like that. And it works well but the the TaskJuggler files are unpleasant to work with, let's say, especially when you get very large and you have a lot of interdependencies. In Smartsheet it basically almost works like like a spreadsheet, except it's designed specifically for schedule development and project planning. So I have up the Fedora35 schedule. There's some stuff that mandatory for internal tooling, but I want to scroll down a little bit through some of these key dates and you can see the final release public availability, the early and the target date number one and then a current target. So the early target date is basically the point at which the entire schedule revolves around. The way we've developed our schedule is we pick the target date and work backwards to all the other milestones. So in essence everything is a certain number of days, weeks behind the target date. And so when you think of it that way it's sort of easy to conceptualize where everything falls and how if you change one thing you change the other. A lot of things are actually tied to whatever the current final target date is, but most are actually based on the early target because for example if we shift the, if we miss the early target and shift to target date number one the current final target date changes, but for example that wouldn't affect the beta release because that's already done, right? So like in most schedule tools you can set a start and a finish and a duration. A lot of these have a zero-day duration because in the Fedora Linux release schedule we're not really tracking individual tasks. It's basically just a lot of milestones because developing a distribution release is such a massive task and with the volunteer community you really can't micromanage down to like the individual task level so we're really looking at milestones here. And then of course you can define cred assessor relationships between you know different elements in the schedule. So for example right now the current final target date is set to start at the same time as line 51 which is the early final starts. You could also have things finish or start when the previous task finishes. You know basically all those other kind of relationships and then you can set offsets. So the final target date is going to be the early date plus one week. Even though right now we only have through F-36 schedules out, basically the plan is always the the early final target date is going to be the third Tuesday of the month and target number one is going to be the fourth Tuesday of the month. And the reason we do that is it's sort of a marketing reason which is you know still pretty important in a schedule and that's because moving back from the early target to the you know sort of public target let's say you know people don't always pay attention to the fact that the early target is really for contributor attention and the target date number one is for public attention. And so if we miss the early date and we hit the date number one which is what usually happens they're still in the same month and so you know going from October 19th to October 26th is still on October it doesn't sound as bad as you know the same one week going from October to November now you're in a different month and that just sort of conceptually sounds different to people. The way we build the schedule is somewhat just based on history so for 33 through 36 because I knew that you know rel 9 planning was going to be happening. I went ahead and made a schedule several years in advance just so rel as a downstream of fedora could you know see what the schedule is and plan accordingly but it's basically you know just save as and start a new schedule. A lot of these tasks are not necessarily things that are still valid there may be things that aren't on there that need to be. So one thing I like to do every so often is go to all the different teams that have tasks in the schedule and just say to them hey is this still valid or are there things you need to add or things that need to be adjusted or the stuff you're not doing anymore. We recently discovered that there was a configuration that needed to be changed in some of the gating testing and since it was relatively new it just hadn't been put on the schedule but we want to make sure that the release engineering team remembers to update that. So I added that task and that's this update green wave product versions and so that way at certain milestones where the different versions that might exist in package updates changes release engineering has a nice succinct list when they look at their tasks for branch day or for you know end-of-life day they can update that accordingly. The schedule and smart sheet isn't very helpful by itself because the community can't see it. The way we fix that is I export it as Microsoft project XML file and then we go to some tooling written by the Red Hat program management team to generate their websites that people see. So this is all on a pack of repo that has schedules back through Fedora 5, Fedora Core 5 and so the file we can look at for example is Fedora schedule.xml and you know it's an XML file so it's not super readable or useful but we have a make file that just calls another make file with basically having a variable and when we do this now it's just generating HTML and ICS versions and JSON versions as well of all of the different ones and then there's a script if you give it the publish option it'll actually just do an rsync to the website so let's look a little bit more at how this works. There is a tool called schedule BGM build Fedora if we look at that it's basically a kind of ugly shell script but what it does is it has you know basically declare a list of the different schedules you want to produce and so this is a point where if we wanted to add another team schedule let's say the llama herder spin had had some tasks that they wanted to have on the schedule we could produce a schedule just for them by adding them to this report. Similarly we could cut out things if there's a team that just doesn't have tasks anymore they're not active and so this is again you see the flag show commands where those flags and smartsheet come into play because it's that limits it to only those only the task is those flags and tasks can have multiple flags. It's one of the tool called schedule convert which is available in PIP and it just generates it throws some html around the table and it's done then in this repo we also have to make it pretty we have an index file which makes just lists it so you're not getting this boring directory listing and that index file also allows us to list the you know to style the current releases and then have historical as well and then because the old version was pretty ugly I wrote some css that you know stylizes it with the fedora colors and you know improve some of the padding and things like that so we'll take a look at what that output looks like in just a moment but both of those can be synced there's a make file in the html directory that basically just rsyncs that stuff over so there is a fedora account group that you need to be in to push to that but then you can just do an rsync and you know set up your ssh configuration so it uses the right key and sets your username correctly and then you can just whoosh it all over there so for example add that exclamation point so we have the current version of the schedule I'm not going to switch the screen sharing again but if I run I go to the html directory and run make publish so it copied that and I refresh and there's the exclamation point easy piece so this is where we try and link people to for the schedule so we'll take a look at fedora linux 35 because that's the you know actively developed one and from that that index page everything starts out with the key schedule which only has 25 tasks and these are sort of like the really things you know across across most of the project that people need to care about but then you can see across the top if you want to look at what the fedora project leader has to do okay Matthew doesn't do a lot around here I guess but you can look at say release engineering and see their tasks and you know the dates remember I talked about how we can add notes or links those show up in the html if you really want to look at all of them that is available the all tasks one but it's not super useful there's just a lot going on you can also navigate back to the last two releases if you wanted to you know go back in time and look at something um I could probably add a go forward in time or release or two that would be kind of helpful this is all the sort of hand coded htmo just gets plopped in at the beginning of the file but that's really you know what gets produced and so we can add new things for teams you know if there are groups we're working with that want to have um you know schedule created because they're doing enough tasks and they want to have this reminder for the most part we sort of rely on people to follow their own schedules there are certain milestones and they are where reminders get sent but generally it's not you know I'm not going to go through each you know each day and see all right does anyone have anything to do do I need to remind them you know it really is sort of a four-year-old guidance and then when we reach certain cross-functional milestones that's usually when there's a little more checking or a coordination from the program management side you can also if you want you can take off the tasks.html and just add ics and don't add a trailing slash and you can download an ics file so you can import that into your calendar and that's going to be the same for you know any of the tasks and there's also a JSON file where you can get it in that format if you want to use it to as input to use some other tooling for example I think the the package or dashboard pulls some of this in I think from the release schedule and uses that to display some milestones and actually now that I think about it it'd be really helpful to have links to those on each schedule page so by the time this video is actually uploaded to YouTube that'll probably be there