> 1. That's quite different from the existing pattern for, say, nightlies: > ``` > https://archive.mozilla.org/pub/firefox/nightly/2023/10/2023-10-30-16-49-30-mozilla-central/firefox-121.0a1.en-US.mac.dmg > ``` I think it would be good to make it more consistent with existing patterns, as much as possible. So something like this may be better then. ``` https://archive.mozilla.org/pub/firefox/integration/edac68e2456cc823720ee9c6915784191d82ad2e-autoland/2022-11-01-00-06-51/<filename>.dmg ``` Where `<filename>` would contain any other information (e.g., OS, build type, etc.) that we need. We could also make the date/time part of the filename but that seems more redundant. I can also check what exactly we use the build date/time for, and if it is only displayed for reference purposes then perhaps we don't have to include it -- will get back to you on this. > 2. In time, we'll end up with a very large top level directory for `/<revision>`. If this is a significant problem (though based on :whimboo's comment perhaps it isn't?) we could figure out how to group them by *something* (maybe the firs two digits of the changeset ID or something -- though not sure if those would be uniformly distributed). I don't think grouping by year and/or year and month would work since there are some edge cases where a push date is not going to match the build date. Since this support has yet to be implemented in mozregression, the exact details from my perspective don't matter too much, as long as we are able to easily search by changeset and also have access to the full date/time, build type, and OS info. So whichever is the most conventional and sensible way you think that this is doable is good with me!
Bug 1773091 Comment 48 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> 1. That's quite different from the existing pattern for, say, nightlies: > ``` > https://archive.mozilla.org/pub/firefox/nightly/2023/10/2023-10-30-16-49-30-mozilla-central/firefox-121.0a1.en-US.mac.dmg > ``` I think it would be good to make it more consistent with existing patterns, as much as possible. So something like this may be better then. ``` https://archive.mozilla.org/pub/firefox/integration/edac68e2456cc823720ee9c6915784191d82ad2e-autoland/2022-11-01-00-06-51/<filename>.dmg ``` Where `<filename>` would contain any other information (e.g., OS, build type, etc.) that we need. We could also make the date/time part of the filename but that seems more redundant. I can also check what exactly we use the build date/time for, and if it is only displayed for reference purposes then perhaps we don't have to include it (but possibly include push time instead, or something else) -- will get back to you on this. > 2. In time, we'll end up with a very large top level directory for `/<revision>`. If this is a significant problem (though based on :whimboo's comment perhaps it isn't?) we could figure out how to group them by *something* (maybe the firs two digits of the changeset ID or something -- though not sure if those would be uniformly distributed). I don't think grouping by year and/or year and month would work since there are some edge cases where a push date is not going to match the build date. Since this support has yet to be implemented in mozregression, the exact details from my perspective don't matter too much, as long as we are able to easily search by changeset and also have access to the full date/time, build type, and OS info. So whichever is the most conventional and sensible way you think that this is doable is good with me!
> 1. That's quite different from the existing pattern for, say, nightlies: > ``` > https://archive.mozilla.org/pub/firefox/nightly/2023/10/2023-10-30-16-49-30-mozilla-central/firefox-121.0a1.en-US.mac.dmg > ``` I think it would be good to make it more consistent with existing patterns, as much as possible. So something like this may be better then. ``` https://archive.mozilla.org/pub/firefox/integration/edac68e2456cc823720ee9c6915784191d82ad2e-autoland/2022-11-01-00-06-51/<filename>.dmg ``` Where `<filename>` would contain any other information (e.g., OS, build type, etc.) that we need. We could also make the date/time part of the filename but that seems more redundant. I can also check what exactly we use the build date/time for, and if it is only displayed for reference purposes then perhaps we don't have to include it (but possibly include push time instead, or something else) -- will get back to you on this. > 2. In time, we'll end up with a very large top level directory for `/<revision>`. If this is a significant problem (though based on :whimboo's comment perhaps it isn't?) we could figure out how to group them by *something* (maybe the first two digits of the changeset ID or something -- though not sure if those would be uniformly distributed). I don't think grouping by year and/or year and month would work since there are some edge cases where a push date is not going to match the build date. Since this support has yet to be implemented in mozregression, the exact details from my perspective don't matter too much, as long as we are able to easily search by changeset and also have access to the full date/time, build type, and OS info. So whichever is the most conventional and sensible way you think that this is doable is good with me!