4 ms·

There's lots of reasons some of which I can't go into details about, but there are some that I can: There is a freeze to the new infrastructure's product featu

by kinlan 3y ago

There's lots of reasons some of which I can't go into details about, but there are some that I can: There is a freeze to the new infrastructure's product features until after the new year and we needed to get this in before then (we can land feed support without a product feature change) The people I have working on the older infrastructure will be on new projects for our team in the new year.

lapcat 3y ago
Were the deadlines, feature freezes, and project reshuffling imposed on you from above, or were they your decisions? In a blog post two months ago you said, "I've taken the decision..." https://web.dev/blog/webdev-migration https://web.dev/blog/webdev-migration There was clearly someone in Google management who decided that RSS could be broken. Why is this important? Well, for example, it seems that the RSS feed was already broken when this important announcement was posted: "Resuming the transition to Manifest V3" https://developer.chrome.com/blog/resuming-the-transition-to-mv3 https://developer.chrome.com/blog/resuming-the-transition-to...
- listmaking 3y ago
  Not the GP but I think that blog post https://web.dev/blog/webdev-migration https://web.dev/blog/webdev-migration you linked explains it pretty clearly? • The people working on web.dev decided to migrate to a common Google site platform, so that they could focus on content rather than maintaining an ad-hoc infrastructure, • That platform happens not to support RSS (yet), so they've done the best they can in the meantime, filing a bug with the platform, creating the https://developer.chrome.com/feeds https://developer.chrome.com/feeds info page acknowledging the issue, and even creating unofficial feeds. You could phrase this as “someone in Google management who decided that RSS could be broken”, but relative to the big decision of whether to spend effort maintaining your own custom infrastructure or just focus on the content, the presence or absence of RSS support is probably just not a big factor. [One could imagine a culture of "never migrate to a new system unless it fully supports every single functionality of the old system", but that (just like "never launch a product/feature unless you're confident you're going to support it forever") is simply not in Google's culture, where there are always ongoing migrations between "the old system that is deprecated and the new system that is not ready yet" — but that is "just" a cultural problem rather than anyone consciously deciding that RSS could be broken.]
  - lapcat 3y ago
    > relative to the big decision of whether to spend effort maintaining your own custom infrastructure or just focus on the content, the presence or absence of RSS support is probably just not a big factor. This is a false dichotomy. I wasn't questioning the decision to migrate platforms, I was questioning "the deadlines, feature freezes, and project reshuffling". > there are always ongoing migrations between "the old system that is deprecated and the new system that is not ready yet" — but that is "just" a cultural problem rather than anyone consciously deciding that RSS could be broken. I disagree, because whenever you migrate, some features are considered essential and others inessential. Someone consciously decided that RSS was among the inessential features in this specific case. The "culture" did not make that specific decision. This is the developer relations team. How can you have relations with developers when they don't even see your announcements? The essential part is the communication with outside developers, not the internal CMS. > they've done the best they can in the meantime, filing a bug with the platform, creating the https://developer.chrome.com/feeds https://developer.chrome.com/feeds info page acknowledging the issue, and even creating unofficial feeds. How were developers supposed to know any of this? I had no idea until now.
    - listmaking 3y 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.
- kinlan 3y ago
  > Were the deadlines, feature freezes, and project reshuffling imposed on you from above, or were they your decisions? They were my decisions based on all the data I had, including launching with what we had. re: "Resuming the transition to Manifest V3" this was posted on the old infrastructure and should have been in your RSS feeds up until late last week when our migration happened - so for just under a month... I can check more to make sure what I am saying is correct, but the migration only happened last week.
  - lapcat 3y ago
    According to my backups, https://developer.chrome.com/feeds https://developer.chrome.com/feeds had XML with <updated>2023-10-17T00:00:00Z</updated> until December 7, then HTML after December 8. So it wasn't entirely broken until December 8 but seems to have been frozen for some time before that.
    - kinlan 3y ago
      Hmm - that shouldn't have been the case, but I can speak to the team to see what might have happened. Thanks for diving in to this.
dagurp 3y ago
There was a bug in the old RSS implementation (the last-updated date was always Jan 1st 1980) so it would be great if you fixed that when you re-add it
- gred 3y ago
  My first quick scan of your comment gave me the impression that you were sarcastically asking for the date bug to be replicated in the new system for "backwards compatibility" purposes. Glad to see, upon reviewing, that I was wrong :-)

by kinlan 3y ago

lapcat 3y ago

Were the deadlines, feature freezes, and project reshuffling imposed on you from above, or were they your decisions? In a blog post two months ago you said, "I've taken the decision..." https://web.dev/blog/webdev-migration https://web.dev/blog/webdev-migration There was clearly someone in Google management who decided that RSS could be broken. Why is this important? Well, for example, it seems that the RSS feed was already broken when this important announcement was posted: "Resuming the transition to Manifest V3" https://developer.chrome.com/blog/resuming-the-transition-to-mv3 https://developer.chrome.com/blog/resuming-the-transition-to...

listmaking 3y ago
Not the GP but I think that blog post https://web.dev/blog/webdev-migration https://web.dev/blog/webdev-migration you linked explains it pretty clearly? • The people working on web.dev decided to migrate to a common Google site platform, so that they could focus on content rather than maintaining an ad-hoc infrastructure, • That platform happens not to support RSS (yet), so they've done the best they can in the meantime, filing a bug with the platform, creating the https://developer.chrome.com/feeds https://developer.chrome.com/feeds info page acknowledging the issue, and even creating unofficial feeds. You could phrase this as “someone in Google management who decided that RSS could be broken”, but relative to the big decision of whether to spend effort maintaining your own custom infrastructure or just focus on the content, the presence or absence of RSS support is probably just not a big factor. [One could imagine a culture of "never migrate to a new system unless it fully supports every single functionality of the old system", but that (just like "never launch a product/feature unless you're confident you're going to support it forever") is simply not in Google's culture, where there are always ongoing migrations between "the old system that is deprecated and the new system that is not ready yet" — but that is "just" a cultural problem rather than anyone consciously deciding that RSS could be broken.]
- lapcat 3y ago
  > relative to the big decision of whether to spend effort maintaining your own custom infrastructure or just focus on the content, the presence or absence of RSS support is probably just not a big factor. This is a false dichotomy. I wasn't questioning the decision to migrate platforms, I was questioning "the deadlines, feature freezes, and project reshuffling". > there are always ongoing migrations between "the old system that is deprecated and the new system that is not ready yet" — but that is "just" a cultural problem rather than anyone consciously deciding that RSS could be broken. I disagree, because whenever you migrate, some features are considered essential and others inessential. Someone consciously decided that RSS was among the inessential features in this specific case. The "culture" did not make that specific decision. This is the developer relations team. How can you have relations with developers when they don't even see your announcements? The essential part is the communication with outside developers, not the internal CMS. > they've done the best they can in the meantime, filing a bug with the platform, creating the https://developer.chrome.com/feeds https://developer.chrome.com/feeds info page acknowledging the issue, and even creating unofficial feeds. How were developers supposed to know any of this? I had no idea until now.
  - listmaking 3y 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.
kinlan 3y ago
> Were the deadlines, feature freezes, and project reshuffling imposed on you from above, or were they your decisions? They were my decisions based on all the data I had, including launching with what we had. re: "Resuming the transition to Manifest V3" this was posted on the old infrastructure and should have been in your RSS feeds up until late last week when our migration happened - so for just under a month... I can check more to make sure what I am saying is correct, but the migration only happened last week.
- lapcat 3y ago
  According to my backups, https://developer.chrome.com/feeds https://developer.chrome.com/feeds had XML with <updated>2023-10-17T00:00:00Z</updated> until December 7, then HTML after December 8. So it wasn't entirely broken until December 8 but seems to have been frozen for some time before that.
  - kinlan 3y ago
    Hmm - that shouldn't have been the case, but I can speak to the team to see what might have happened. Thanks for diving in to this.

dagurp 3y ago

There was a bug in the old RSS implementation (the last-updated date was always Jan 1st 1980) so it would be great if you fixed that when you re-add it

gred 3y ago
My first quick scan of your comment gave me the impression that you were sarcastically asking for the date bug to be replicated in the new system for "backwards compatibility" purposes. Glad to see, upon reviewing, that I was wrong :-)