Bug 1883655 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

This is going to require communications with the extensions team to make sure we didn't forget anything, but these are the things I'm aware of that we'd back up in the profile directory related to extensions:

1. extensions.json
2. addonStartup.json.lz4
3. extension-settings.json
4. extension-store-permissions/data.safe.bin
5. The sum size of everything under extensions/

There's some shared infrastructure here with bug 1883642 (for the metrics.yaml file, for setting up the private method in `BackupService` that does measurement, and for test infrastructure), so if this is being worked on in parallel by two people, they might want to coordinate a little bit so that they don't stomp on each other's toes a bit. What I'd recommend there is to have the person working on bug 1883642 sketch out the method and the test infrastructure first, and post that as a WIP, and then the person working on this bug pulls that bug down and creates a new commit on top of it with these measurements.

Bug 1883642 will need to land first, but if the initial WIP patch isn't too different from what ultimately gets landed, I suspect rebase conflicts won't be that bad.

Here's the list of things to do for this bug:

1. Talk to someone from the extensions team about this. My short list of candidates is: rpl, willdurand, mixedpuppy or robwu. We need to make sure we're not missing any files that might be extension-related here.
2. Create `quantity` probes for each of the items listed above
3. Inside the private method from the WIP that does measurements, using `IOUtils.stat` to read the sizes of each of these things, and write the probes
4. Add tests for those probes. This might be tricky - I'm not entirely sure how easy it is to install an XPI in an xpcshell test that gets puts into the extensions/ directory. That's something to work out with whoever you talk to in (1).

And of course, don't forget to request a data review for the probes. Maybe even do that after (2), so that the data review can occur in parallel to working on 3-4.
This is going to require communications with the extensions team to make sure we didn't forget anything, but these are the things I'm aware of that we'd back up in the profile directory related to extensions:

1. extensions.json
2. addonStartup.json.lz4
3. extension-settings.json
4. extension-store-permissions/data.safe.bin
5. The sum size of everything under extensions/

There's some shared infrastructure here with bug 1883642 (for the metrics.yaml file, for setting up the private method in `BackupService` that does measurement, and for test infrastructure), so if this is being worked on in parallel by two people, they might want to coordinate a little bit so that they don't stomp on each other's toes a bit. What I'd recommend there is to have the person working on bug 1883642 sketch out the method and the test infrastructure first, and post that as a WIP, and then the person working on this bug pulls that bug down and creates a new commit on top of it with these measurements.

Bug 1883642 will need to land first, but if the initial WIP patch isn't too different from what ultimately gets landed, I suspect rebase conflicts won't be that bad.

Here's the list of things to do for this bug:

1. Talk to someone from the extensions team about this. My short list of candidates is: rpl, willdurand, mixedpuppy or robwu. We need to make sure we're not missing any files that might be extension-related here.
2. Create `quantity` probes for each of the items listed above
3. Inside the private method from the WIP that does measurements, using `IOUtils.stat` to read the sizes of each of these things, and write the probes
4. Add tests for those probes. This might be tricky - I'm not entirely sure how easy it is to install an XPI in an xpcshell test that gets puts into the extensions/ directory. That's something to work out with whoever you talk to in (1).

And of course, don't forget to request a data review for the probes. Maybe even do that after (2), so that the data review can occur in parallel to working on 3-4. Don't forget about `./mach data-review` to help you out!
This is going to require communications with the extensions team to make sure we didn't forget anything, but these are the things I'm aware of that we'd back up in the profile directory related to extensions:

1. extensions.json
2. addonStartup.json.lz4
3. extension-settings.json
4. extension-store-permissions/data.safe.bin
5. The sum size of everything under extensions/
6. The contents of `browser-extension-data`

There's some shared infrastructure here with bug 1883642 (for the metrics.yaml file, for setting up the private method in `BackupService` that does measurement, and for test infrastructure), so if this is being worked on in parallel by two people, they might want to coordinate a little bit so that they don't stomp on each other's toes a bit. What I'd recommend there is to have the person working on bug 1883642 sketch out the method and the test infrastructure first, and post that as a WIP, and then the person working on this bug pulls that bug down and creates a new commit on top of it with these measurements.

Bug 1883642 will need to land first, but if the initial WIP patch isn't too different from what ultimately gets landed, I suspect rebase conflicts won't be that bad.

Here's the list of things to do for this bug:

1. Talk to someone from the extensions team about this. My short list of candidates is: rpl, willdurand, mixedpuppy or robwu. We need to make sure we're not missing any files that might be extension-related here.
2. Create `quantity` probes for each of the items listed above
3. Inside the private method from the WIP that does measurements, using `IOUtils.stat` to read the sizes of each of these things, and write the probes
4. Add tests for those probes. This might be tricky - I'm not entirely sure how easy it is to install an XPI in an xpcshell test that gets puts into the extensions/ directory. That's something to work out with whoever you talk to in (1).

And of course, don't forget to request a data review for the probes. Maybe even do that after (2), so that the data review can occur in parallel to working on 3-4. Don't forget about `./mach data-review` to help you out!
This is going to require communications with the extensions team to make sure we didn't forget anything, but these are the things I'm aware of that we'd back up in the profile directory related to extensions:

1. extensions.json
2. addonStartup.json.lz4
3. extension-settings.json
4. extension-store-permissions/data.safe.bin (if it exists, since it's only currently used on Nightly)
5. extension-preferences.json (since bug 1646182 is still open)
5. The sum size of everything under extensions/
6. The contents of `browser-extension-data`

There's some shared infrastructure here with bug 1883642 (for the metrics.yaml file, for setting up the private method in `BackupService` that does measurement, and for test infrastructure), so if this is being worked on in parallel by two people, they might want to coordinate a little bit so that they don't stomp on each other's toes a bit. What I'd recommend there is to have the person working on bug 1883642 sketch out the method and the test infrastructure first, and post that as a WIP, and then the person working on this bug pulls that bug down and creates a new commit on top of it with these measurements.

Bug 1883642 will need to land first, but if the initial WIP patch isn't too different from what ultimately gets landed, I suspect rebase conflicts won't be that bad.

Here's the list of things to do for this bug:

1. Talk to someone from the extensions team about this. My short list of candidates is: rpl, willdurand, mixedpuppy or robwu. We need to make sure we're not missing any files that might be extension-related here.
2. Create `quantity` probes for each of the items listed above
3. Inside the private method from the WIP that does measurements, using `IOUtils.stat` to read the sizes of each of these things, and write the probes
4. Add tests for those probes. This might be tricky - I'm not entirely sure how easy it is to install an XPI in an xpcshell test that gets puts into the extensions/ directory. That's something to work out with whoever you talk to in (1).

And of course, don't forget to request a data review for the probes. Maybe even do that after (2), so that the data review can occur in parallel to working on 3-4. Don't forget about `./mach data-review` to help you out!
This is going to require communications with the extensions team to make sure we didn't forget anything, but these are the things I'm aware of that we'd back up in the profile directory related to extensions:

1. extensions.json
2. addonStartup.json.lz4
3. extension-settings.json
4. extension-store-permissions/data.safe.bin (if it exists, since it's only currently used on Nightly)
5. extension-preferences.json (since bug 1646182 is still open)
5. The sum size of everything under extensions/
6. The contents of `browser-extension-data`
7. storage-sync-v2.sqlite

There's some shared infrastructure here with bug 1883642 (for the metrics.yaml file, for setting up the private method in `BackupService` that does measurement, and for test infrastructure), so if this is being worked on in parallel by two people, they might want to coordinate a little bit so that they don't stomp on each other's toes a bit. What I'd recommend there is to have the person working on bug 1883642 sketch out the method and the test infrastructure first, and post that as a WIP, and then the person working on this bug pulls that bug down and creates a new commit on top of it with these measurements.

Bug 1883642 will need to land first, but if the initial WIP patch isn't too different from what ultimately gets landed, I suspect rebase conflicts won't be that bad.

Here's the list of things to do for this bug:

1. Talk to someone from the extensions team about this. My short list of candidates is: rpl, willdurand, mixedpuppy or robwu. We need to make sure we're not missing any files that might be extension-related here.
2. Create `quantity` probes for each of the items listed above
3. Inside the private method from the WIP that does measurements, using `IOUtils.stat` to read the sizes of each of these things, and write the probes
4. Add tests for those probes. This might be tricky - I'm not entirely sure how easy it is to install an XPI in an xpcshell test that gets puts into the extensions/ directory. That's something to work out with whoever you talk to in (1).

And of course, don't forget to request a data review for the probes. Maybe even do that after (2), so that the data review can occur in parallel to working on 3-4. Don't forget about `./mach data-review` to help you out!

Back to Bug 1883655 Comment 0