Hacker News new | ask | show | jobs
by listmaking 917 days ago
The freeze "until after the new year" is just the end-of-year freeze to avoid production breakage when a lot of people are on vacation: it's an extension of the principle of not deploying on Friday evenings / weekends; lots of companies have such a freeze. Once you've decided a couple of months earlier to do a migration, doing it "before the freeze" is also a natural deadline to pick, for migrating to the new infrastructure, and for people working on the old infrastructure to complete the migration and move to other projects. I'm not on the team but these all seem like logical choices.

And yes, in the decision between "keep maintaining a custom infrastructure" and "switch to a common infrastructure", someone must have decided that RSS support is not an essential feature whose lack should block (or indefinitely postpone) the migration; this seems reasonable and what my previous post was about, including the "probably just not a big factor" bit you quoted above. It looks like they're planning to add this support though.
1 comments
lapcat 917 days ago
> The freeze "until after the new year" is just the end-of-year freeze to avoid production breakage when a lot of people are on vacation

There was production breakage! The RSS feeds broke. That's the entire point of this HN submission and discussion.

> Once you've decided a couple of months earlier to do a migration, doing it "before the freeze" is also a natural deadline to pick, for migrating to the new infrastructure

Why? Migrations almost always break stuff, right? So why would you break stuff when "a lot of people are on vacation" and thus can't fix the breakage? It seems to me the natural and logical choice would be to wait until after the new year to migrate. What sense does it make to break stuff and then go on vacation?

> RSS support is not an essential feature whose lack should block (indefinitely postpone) the migration; this seems natural (especially if you think you can add it back in a few weeks / months)

It's interesting that you say "indefinitely" postpone but then turn around right away and say "a few weeks/ months".

link
freedomben 917 days ago
I don't really disagree with you, but I've been on the other end of this before and there was a major incentive to get it in before the break: all the context in our heads.

If we waited several weeks until after the christmas break, we'd lose a lot of mental context. It's also a horrible dark cloud hanging over your head. When dealing with a big migration, it's really ideal to do it while everything is still fresh. Context switching can be very expensive

link
listmaking 917 days ago
Sorry that this conversation is going in circles. At first, I was talking about the culture of migrating to a new system when it supports ~75% of the features (by importance) of the old, rather than closer to 100%. I would find it reasonable for some team to judge that RSS support is not in the crucial 75% (and its lack would not constitute production breakage); clearly you disagree. That's fine.

As for the rest, I was just explaining the general idea of a production freeze. If you're going to stop trying to make changes by a certain date "to be safe"; then that's the freeze date. Equivalently: people keep trying (and sometimes rushing) to do things until the actual freeze date. The date is early enough (quite a bit earlier than Dec 24) so that there's still enough time and people left to fix things or roll back, if there are genuine emergencies. This replaces the risk of production breakage with the risk of embarrassment/questions from asking for approval for an emergency fix during the freeze period, so people will still only do things they're fairly confident will be safe. Anyway, none of this is relevant unless lack of RSS support is considered a production breakage, which is the very point of disagreement here.

Sorry about the "few weeks / months" comment; I was editing it out while you were posting your comment. But yes, when deciding whether something is a blocker, it's safer to assume that it can take indefinitely long (until it actually exists), even if you think (or have been promised) that it will be quick. It's the difference between taking the mean versus the 95th percentile of the distribution of time estimates.

link
lapcat 917 days ago
> its lack would not constitute production breakage

Of course it's production breakage. You can't redefine it to not be "production" breakage just because you make a distinction between essential and non-essential features to pull the trigger on the migration. If the migration only supports 75% of the previous features, then 25% of the previous features are broken in production after the migration. If you're ok with that, then ok, but let's not pretend there's no production breakage. The RSS feeds were in production, and then they broke. That's production breakage. What else would you call it?

> As for the rest, I was just explaining the general idea of a production freeze.

I don't need that explained.

> Anyway, none of this is relevant unless lack of RSS support is considered a production breakage, which is the very point of disagreement here.

I think you're the only one who doesn't think RSS support isn't production breakage. Otherwise, Google wouldn't be "actively working on a solution."

link