Right, I wasn't su this will in any way fix any aspect of imap sync. Rather I was curious if it might make help development/debugging of the imap fixes, and then after shipping help with the inevitable issues that will come. Parallel ideas: 1) we don't know when they will actually remove the current code, which could force to adopt this at an inconvenient time in our own development process - there's nothing imminent in any of the blocking bugs, but that can always change. And as you stated our threading is complex, so we wouldn't want to risk being forced to land this late in an esr development cycle. 2) as you indicate this may complicate fixing the imap sync problems, so is it preferable to do these at the same time as one package, or do them at different times, and if so in which order?
Bug 1618934 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Right, I wasn't suggesting this will in any way fix any aspect of imap sync. Rather I was curious if it might make help development/debugging of the imap fixes, and then after shipping help with the inevitable issues that will come. Parallel ideas: 1) we don't know when they will actually remove the current code, which could force to adopt this at an inconvenient time in our own development process - there's nothing imminent in any of the blocking bugs, but that can always change. And as you stated our threading is complex, so we wouldn't want to risk being forced to land this late in an esr development cycle. 2) as you indicate this may complicate fixing the imap sync problems, so is it preferable to do these at the same time as one package, or do them at different times, and if so in which order?