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.
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.
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...
> 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.
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.
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?
Demanding >9GB of disk space to build a browser extension is insane.
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-c...
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?
That anyone dumber than such a reviewer cannot sneak malicious extensions in.
Which, sadly, is probably a non-trivial number of submissions.
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.
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.
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.
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 do that job 8+ hours a day for little pay?
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.