Given the size the community has grown to and concerns around our current approach to maintenance, I’d like to get some feedback on when we should look to schedule maintenance going forward.
There’s two cases covered by the poll, so please choose the all options that fit your preferences.
Case 1: Non-interactive Maintenance This covers any maintenance where we don’t actively need to monitor the upgrade process; Copying data from one location to another, etc. (Usually, this could be left overnight and brought back up in the morning)
Case 2: Interactive Maintenance This covers any maintenance that requires us to perform a series of actions and continually monitor the process to ensure no issues; Upgrading Mastodon or Lemmy, database migration, or upgrading the Kubernetes cluster. (Usually, this would need to occur during the day due to time constraints)
To vote, please find the corresponding pinned comments and upvote them!
If you’ve got any questions, concerns, etc. please leave them below and we’ll get back to them asap!
Case 2: Interactive Maintenance Poll
Case 2 - Evening (5 PM to 10 PM)
Case 2 - Daytime (8 AM to 5 PM)
deleted by creator
Case 2 - Overnight (10 PM to 8 AM)
Case 1: Non-Interactive Maintenance Poll
Case 1 - Daytime (8 AM to 5 PM)
Case 1 - Evening (5 PM to 10 PM)
Case 1 - Overnight (10 PM to 8 AM)
I’m not under any illusion that this is a professional, 99.99% uptime type of service. You’re some people (heck, maybe just you, I don’t know how many there are) that are doing this out of the goodness of your heart. Maintenances have been as brief as they could be and the uptime is good. Work around what’s best for you guys.
Are these times in UTC or a localized timezone? Are you planning this maintenance on weekdays or weekends? My usage differs greatly between the traditional work week and weekend.
US Mountain Time! (I put that on the other posts, but forgot here, my bad!)
Maintenance will typically be as needed, but I think I’ll need to make a new poll for capturing weekend / weekday preferences, I hadn’t thought about differentiating that.