5 ms·

Yeah, that's bizarre. If my team were responsible for a bug like this, we'd be fixing it before we went home.

saagarjha 8y ago
The team might be able to fix it today, but the fix needs to go through testing and then be built alongside the rest of iOS (a multi-hour process). I wouldn’t be surprised if this takes two or three days to roll out.
- taftster 8y ago
  They obviously didn't test it the first time out. Why do they need to test it this time?
  - saagarjha 8y ago
    I don't see a bug in the patch to fix this bug going over very well with the press.
    - Gigablah 8y ago
      It's not like they haven't done it before :) https://www.theguardian.com/technology/2017/nov/30/apple-macos-high-sierra-fix-breaks-file-sharing-password-security-flaw-emergency-patch https://www.theguardian.com/technology/2017/nov/30/apple-mac...
      - saagarjha 8y ago
        Yeah, that's my point ;)
- grogenaut 8y ago
  You didn't even bring into consideration the app store approval process which can take 2-3 weeks and likely would reject this as a feature removal without user notification.
  - saagarjha 8y ago
    The update notes might include it ;)
briandear 8y ago
Do you know how long it takes to build iOS? It isn’t a “git deploy” and you’re done.
- 55555 8y ago
  How long does it take?
  - saagarjha 8y ago
    Several hours to a day, depending on how many components fail to build.
    - grogenaut 8y ago
      So every bugfix is a rebuild from current, not from "released"? This seems like not a real process.
      - deleted 8y ago
        [deleted]
      - saagarjha 8y ago
        I'm not sure if they have a special process for emergency bug fixes, but for internal testing a new build is done about daily from source, yes. One of these ends up being polished a bit and sent out to users.
        grogenaut 8y ago
        So my confusion is generally it's best practices to keep branches off of these releases and then just apply fixes to that. Even better is if you can keep the meta build around or use a distributed build system so that you can do incremental builds for patches to that release getting the time way down, unless of course you're changing core libraries and have to recompile or re-link everything. It would seem a risk to me security wise that there wasn't a fast way to get patches out to prod per app or fo the os that don't require full blown rebuilds. I guess I may also not be accounting for the QA process.

The team might be able to fix it today, but the fix needs to go through testing and then be built alongside the rest of iOS (a multi-hour process). I wouldn’t be surprised if this takes two or three days to roll out.

taftster 8y ago
They obviously didn't test it the first time out. Why do they need to test it this time?
- saagarjha 8y ago
  I don't see a bug in the patch to fix this bug going over very well with the press.
  - Gigablah 8y ago
    It's not like they haven't done it before :) https://www.theguardian.com/technology/2017/nov/30/apple-macos-high-sierra-fix-breaks-file-sharing-password-security-flaw-emergency-patch https://www.theguardian.com/technology/2017/nov/30/apple-mac...
    - saagarjha 8y ago
      Yeah, that's my point ;)
grogenaut 8y ago
You didn't even bring into consideration the app store approval process which can take 2-3 weeks and likely would reject this as a feature removal without user notification.
- saagarjha 8y ago
  The update notes might include it ;)

briandear 8y ago

Do you know how long it takes to build iOS? It isn’t a “git deploy” and you’re done.

55555 8y ago
How long does it take?
- saagarjha 8y ago
  Several hours to a day, depending on how many components fail to build.
  - grogenaut 8y ago
    So every bugfix is a rebuild from current, not from "released"? This seems like not a real process.
    - deleted 8y ago
      [deleted]
    - saagarjha 8y ago
      I'm not sure if they have a special process for emergency bug fixes, but for internal testing a new build is done about daily from source, yes. One of these ends up being polished a bit and sent out to users.
      - grogenaut 8y ago
        So my confusion is generally it's best practices to keep branches off of these releases and then just apply fixes to that. Even better is if you can keep the meta build around or use a distributed build system so that you can do incremental builds for patches to that release getting the time way down, unless of course you're changing core libraries and have to recompile or re-link everything. It would seem a risk to me security wise that there wasn't a fast way to get patches out to prod per app or fo the os that don't require full blown rebuilds. I guess I may also not be accounting for the QA process.