3 ms·

> that's because you didn't follow instructions and are in the wrong directory. You just need to have a shell script in the root directory that assumes the per

> that's because you didn't follow instructions and are in the wrong directory. You just need to have a shell script in the root directory that assumes the person running it has 0 clue about your extension. Also some of this reminds me of Apple. They clear something up, then bring it up again the next time review is needed.

adrian17 2y ago
Even this we had issues with - we wrapped the entire build environment and script in a dockerfile, but depending on system configuration you may or may not have to run docker with sudo - it just so happened that reviewer's environment required it, while ours didn't, and the reviewer needed specific instructions on what to do in this case. Another time, they failed the review because the reviewer's VM _ran out of disk space_ (which we only learned after digging into the issue, as the first report just mentioned "build errors"; according to later inquiries the VM had ~9GB available) and we had to add some extra build logic to delete intermediate files, just for them. The build is quite large because it involves rust->wasm compilation, but I'd still expect the reviewer's machine to have a bit more space...
- cxr 2y ago
  Everything described here sounds like your team, your extension, and your software development process are the problem. Demanding >9GB of disk space to build a browser extension is capital F, capital I Fucking Insane. Go yell at the Rust folks about their shitty toolchain and your engineering lead for buying into it instead of blaming people who have enough problems as it is just coming into contact with the quagmire you described.
  - adrian17 2y ago
    The 9GB limit was not just the Rust stuff, that was for the entire docker environment with compiler, JRE, node, wasm toolkit, typescript, webpack etc. Yes, we need all of these to make a "true" reproducible build from scratch. > to build a browser extension It shares 99% of code with a desktop application; you can compile it to wasm while preserving most features. The extension wraps the wasm. For reference, when making a single clean build, the `target/` dir reaches 700MB.
    - cxr 2y ago
      > The 9GB limit was not just the Rust stuff, that was for the entire docker environment with compiler, JRE, node, wasm toolkit, typescript, webpack etc. None of this is surprising or exculpatory. Demanding >9GB of disk space to build a browser extension is insane. > we need all of these to make a "true" reproducible build from scratch You need and them to reproduce your build. You definitely don't need all of them to build what you're building.
      - freedomben 2y ago
        You certainly are confident that you know more about GP's situation than they do. When you took your desktop app and built a browser extension version, did you really rewrite the entire app in vanilla JavaScript just got the Mozilla review team as you seem to be expecting GP to have done? How long did it take you? What sort of opportunity cost was there from investing your time on that instead of adding value to your product?
        cxr 2y ago
        For someone who opened their post with a first sentence like that, you're making a lot of (bad) assumptions on your end; most of your questions are unanswerable or have answers that you are clearly expecting to go the other way. Demanding >9GB of disk space to build a browser extension is insane.
    - freedomben 2y ago
      Thank you for setting such a good example. If I were you, I don't know that I could have given such a good and dispassionate reply to such an arrogant, overconfident, and rude comment as you did. Your comments are not only technically interesting, but also epitomize. What a healthy online community should be. Thank you for doing what you do!
- dotproto 2y ago
  Simeon from the Firefox Add-ons team here. Sorry about the rocky experience. I realize this is a bit late for your situation, but earlier this year the source code submission docs were updated with information about the default reviewer build environment[1]. It's not a huge improvement, but it sounds like one thing we could do to improve the communications process around build errors is to include a link to this documentation in the notification email sent to developers. I'll create a ticket for this now. [1]: https://extensionworkshop.com/documentation/publish/source-code-submission/#default-reviewer-build-environment https://extensionworkshop.com/documentation/publish/source-c...
akira2501 2y ago
> that assumes the person running it has 0 clue about your extension. I would tend to assume that a person given responsibility for reviewing this software, supposedly to protect end users, would not be this clueless. What value is the "Firefox Store" actually offering then?
- ethbr1 2y ago
  > What value is the "Firefox Store" actually offering then? That anyone dumber than such a reviewer cannot sneak malicious extensions in. Which, sadly, is probably a non-trivial number of submissions.
  - akira2501 2y ago
    > That anyone dumber than such a reviewer cannot sneak malicious extensions in. Although people smarter than such a reviewer are free to? What kind of standard is that? > Which, sadly, is probably a non-trivial number of submissions. Then they're not, as an organization, actually capable of doing what they're promising here. There are more ways to get this wrong than to get it right, and borrowing the Google strategy of just not caring about your end users seems completely inappropriate for a non-profit like Mozilla.
    - ethbr1 2y ago
      > What kind of standard is that? That's the standard of all currated stores. We can argue about whether Mozilla's reviewer skillset is too low, but there's always going to be someone smarter than a reviewer, when reviewing is a cost center that companies want to spend the minimum amount of money on.
      - akira2501 2y ago
        > That's the standard of all currated stores. This seems to ignore how boutique stores and high end retail operates. This is the standard of rent seeking middlemen stores. You still haven't answered why this model is appropriate for Firefox. > We can argue about whether Mozilla's reviewer skillset is too low We're not. I'm pointing out how simply taking the opposing view reveals that your reasoning could not possibly be correct. > reviewing is a cost center that companies want to spend the minimum amount of money on. Which is weird because I assumed the cost of re-creating the plugin yourself would be much higher than that. It's almost like continual failure of these simplistic analyses reveal that a broader examination is required.

adrian17 2y ago

Even this we had issues with - we wrapped the entire build environment and script in a dockerfile, but depending on system configuration you may or may not have to run docker with sudo - it just so happened that reviewer's environment required it, while ours didn't, and the reviewer needed specific instructions on what to do in this case. Another time, they failed the review because the reviewer's VM _ran out of disk space_ (which we only learned after digging into the issue, as the first report just mentioned "build errors"; according to later inquiries the VM had ~9GB available) and we had to add some extra build logic to delete intermediate files, just for them. The build is quite large because it involves rust->wasm compilation, but I'd still expect the reviewer's machine to have a bit more space...

cxr 2y ago
Everything described here sounds like your team, your extension, and your software development process are the problem. Demanding >9GB of disk space to build a browser extension is capital F, capital I Fucking Insane. Go yell at the Rust folks about their shitty toolchain and your engineering lead for buying into it instead of blaming people who have enough problems as it is just coming into contact with the quagmire you described.
- adrian17 2y ago
  The 9GB limit was not just the Rust stuff, that was for the entire docker environment with compiler, JRE, node, wasm toolkit, typescript, webpack etc. Yes, we need all of these to make a "true" reproducible build from scratch. > to build a browser extension It shares 99% of code with a desktop application; you can compile it to wasm while preserving most features. The extension wraps the wasm. For reference, when making a single clean build, the `target/` dir reaches 700MB.
  - cxr 2y ago
    > The 9GB limit was not just the Rust stuff, that was for the entire docker environment with compiler, JRE, node, wasm toolkit, typescript, webpack etc. None of this is surprising or exculpatory. Demanding >9GB of disk space to build a browser extension is insane. > we need all of these to make a "true" reproducible build from scratch You need and them to reproduce your build. You definitely don't need all of them to build what you're building.
    - freedomben 2y ago
      You certainly are confident that you know more about GP's situation than they do. When you took your desktop app and built a browser extension version, did you really rewrite the entire app in vanilla JavaScript just got the Mozilla review team as you seem to be expecting GP to have done? How long did it take you? What sort of opportunity cost was there from investing your time on that instead of adding value to your product?
      - cxr 2y ago
        For someone who opened their post with a first sentence like that, you're making a lot of (bad) assumptions on your end; most of your questions are unanswerable or have answers that you are clearly expecting to go the other way. Demanding >9GB of disk space to build a browser extension is insane.
  - freedomben 2y ago
    Thank you for setting such a good example. If I were you, I don't know that I could have given such a good and dispassionate reply to such an arrogant, overconfident, and rude comment as you did. Your comments are not only technically interesting, but also epitomize. What a healthy online community should be. Thank you for doing what you do!
dotproto 2y ago
Simeon from the Firefox Add-ons team here. Sorry about the rocky experience. I realize this is a bit late for your situation, but earlier this year the source code submission docs were updated with information about the default reviewer build environment[1]. It's not a huge improvement, but it sounds like one thing we could do to improve the communications process around build errors is to include a link to this documentation in the notification email sent to developers. I'll create a ticket for this now. [1]: https://extensionworkshop.com/documentation/publish/source-code-submission/#default-reviewer-build-environment https://extensionworkshop.com/documentation/publish/source-c...

akira2501 2y ago

> that assumes the person running it has 0 clue about your extension. I would tend to assume that a person given responsibility for reviewing this software, supposedly to protect end users, would not be this clueless. What value is the "Firefox Store" actually offering then?

ethbr1 2y ago
> What value is the "Firefox Store" actually offering then? That anyone dumber than such a reviewer cannot sneak malicious extensions in. Which, sadly, is probably a non-trivial number of submissions.
- akira2501 2y ago
  > That anyone dumber than such a reviewer cannot sneak malicious extensions in. Although people smarter than such a reviewer are free to? What kind of standard is that? > Which, sadly, is probably a non-trivial number of submissions. Then they're not, as an organization, actually capable of doing what they're promising here. There are more ways to get this wrong than to get it right, and borrowing the Google strategy of just not caring about your end users seems completely inappropriate for a non-profit like Mozilla.
  - ethbr1 2y ago
    > What kind of standard is that? That's the standard of all currated stores. We can argue about whether Mozilla's reviewer skillset is too low, but there's always going to be someone smarter than a reviewer, when reviewing is a cost center that companies want to spend the minimum amount of money on.
    - akira2501 2y ago
      > That's the standard of all currated stores. This seems to ignore how boutique stores and high end retail operates. This is the standard of rent seeking middlemen stores. You still haven't answered why this model is appropriate for Firefox. > We can argue about whether Mozilla's reviewer skillset is too low We're not. I'm pointing out how simply taking the opposing view reveals that your reasoning could not possibly be correct. > reviewing is a cost center that companies want to spend the minimum amount of money on. Which is weird because I assumed the cost of re-creating the plugin yourself would be much higher than that. It's almost like continual failure of these simplistic analyses reveal that a broader examination is required.