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...
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.
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.
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.
> 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.
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?
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.
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!
> 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.
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.
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.
You think the best analogy for the Firefox extension store is boutique brick and mortar retail?
A minimal cost reviewer model isn't appropriate to Firefox.
But, example counterargument as to why it might be: Firefox needs to ensure they don't open themselves up liability but doesn't want to fully fund/staff a review team.
Would you run a foundation that forces it's users to be dependent on such a job?
Ya'll are putting the cart before the horse. I'm not being critical of the reviewer but of the large non profit organization that is responsible for creating this failure. Which apparently only exists to pantomime what the for profit players have built and is unsurprisingly equally wasteful of open source developers time and skill set.
Why does Firefox even need a curated "store?" They could have built anything better. I'm sure they were paid, er given "donations," that ensured they would never try. And from what everyone has been saying here those donations got exactly what they were intended to get.
Even Hacker News seems to unquestioningly assume this is a rational way to manage an open source plugin ecosystem. That this is the fault of the plugin author somehow or the store reviewer somehow. It's really disappointing to see.
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.