[Firefox] Set up process for submission of builds to AMO #1166
Comments
|
Hi @AlexVallat! Thanks for reaching out and agreeing to help out with this. It's deeply appreciated. My understanding is that every time an update is submitted to AMO, the entry gets put back at the end of the queue again, right? If so, it might be wise to only submit every-other-update (or selectively based on the importance) to make sure updates _ever_ get delivered. Someone mentioned that it's against AMO's terms to serve updates to the extension directly from another server (bypassing AMO). Do you know whether that's true, Alex? Experimental status until we have a v1.0 is probably a good idea. Thanks again — we'll get #1150 merged shortly here. |
|
At the moment, in Experimental (preliminary review) status, I'm pretty sure that each release will go on to the back of the queue again, yes, so releases shouldn't be made too frequently. Once a Full Review has been done, you are also allowed to publish developer channel releases which are available very quickly, so you'd be able to submit more frequent updates in between full releases. What is your current thinking regards frequency of "releases" and "dev builds" - is the idea going to be to have a bleeding edge latest build .xpi and a separate "release" .xpi that's thought to be more stable? Is that just going to be a point-in-time that didn't get too many issues reported, or are you actually going to have branches for releases? You are allowed to host and release extensions yourself, in which case you serve updates to the extension yourself too. That is probably a good model to follow if you want people to be able to update frequently to the very latest dev versions; you host a manifest file on your own server and Firefox will check that for updates, and pull down the latest version whenever you make it available. What you can not do is have an extension installed from AMO that updates itself outside of AMO - if you installed it from AMO, that's where it will update from too. |
|
@AlexVallat thanks for the info; that's very good to know. Here are my thoughts, if you don't mind me sharing:
What do you think? |
|
I think you're right. There's a degree of trust and respectability associated with being hosted on AMO that I think we'd be unwise to ignore. I agree that, absent a QA team and automated testing, dev builds are going to be broken. We must rely on helpful people running the bleeding-edge reporting issues, and fixing them as they arise. It would be considerate, in return, if we make it as easy as possible for those willing to do this job to keep up to date with those bleeding-edge builds, and I'm therefore in favour of having them served with updates directly from us. That is, if you are willing to host the updates manifest somewhere on https://chrismatic.io/ublock/ ? The format needed is documented here Update RDF Format, and there's a helpful article on the whole process at borngeek. Ultimately, though, I think we'd want some sort of automated system for generating this RDF file (or have it generated dynamically server-side?). I had a quick look around to see if anyone already had such a system published, but didn't see anything immediately promising, unfortunately. Are you then also planning to host 'release' builds, or would those only be the ones published through AMO? It simplifies things quite a lot if the distinction is that the release goes on AMO, dev build outside it, but that does mean a considerable delay before the release build is available due to the review process. |
|
YouTube Center Developer Version updates through GitHub (Firefox and Chrome versions) |
Precisely. Same goes for Safari's |
|
@mikhaelkh sure. The problem is coming up with policies for how updates work for different installation methods — how a user that installed uBlock from AMO gets updates, vs. a user that dragged the |
Just one small addition: Sometimes later this year (if I remember correctly) Firefox will only accept "signed" add-ons. It will still be possible to host an add-on on your own site, but an AMO account is needed as it will provide your personal key which will be used for signing. |
|
@d4k0 oh neat — and that's still while having the listing on AMO? |
Well, I think add-ons on AMO will be signed automatically, so there shouldn't be any problem if you continue to publish uBlock there. It's only necessary to do it manually if you want to host an add-on on your own site. According to Mozilla this is done in order to improve security, but so far there isn't much information on how the whole process will look like (there's still some time, it will be introduced at the end of this year if I remember correctly). More information can be found here: https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ |
|
@d4k0 I might've miscommunicated; I'm sorry. What I meant was: can you still have the listing on AMO while hosting the actual add-on files on one's own site? |
|
So, reading that blog post, it looks like all releases will have to be uploaded to AMO. After it's been uploaded and signed, we then have the choice of either hosting it on AMO, or hosting it ourselves. You can't have a listing on AMO point to a self-hosted .xpi though. As I understand it, if we're hosting it ourselves then it only needs to pass automated testing, not manual review (unless it fails automated testing, but hopefully we could instead fix it to pass). If we are hosting it on AMO then it must also pass manual review. So, that changes things a bit. Is it worth implementing an automatically updating self-hosted system if it's going to be broken as soon as this system goes live? Unless there's a way of automating the upload to AMO, download signed .xpi, and publish then it's not going to work. It's not realistic to have a frequently updated system that involves manually uploading, downloading, and publishing each .xpi Once the signing system is live, if we're going to have to upload to AMO anyway, then we may as well just allow them to host it too, on the development channel. |
|
Let's have the thing clear about the future change on signing add-on on FIrefox: When it will happen Power-Users & Dev will have access to an "Unbranded" version of Firefox that don't check add-on for being signed or not. The "Unbranded" version of Firefox will be EXACTLY the same as the Fireox release except for the "branding" and logo (Like the Firefox Nightly). Only the branded versions will have the signing verification NOT the unbranded version... So no worry here for beta testers/Power Userrs like me since most of us will use the "unbranded version" to be able to "tweak" XPI files wihout havin to submit it to AMO. GL ! |
|
Hello, why don't you submit the last release version 0.9.3.0 to AMO ? Because the last who was proposed, 0.9.1.0, have bugs and the 0.8.8.2 become to be old. And the success of your addon will be important, you alreday have more than 120 000 users and many peoples have enought whith AdBlock Plus and its commercial policy, a free open sourece efficient addon can have a place. Thank for your work. |
|
@alain1978 AFAIK every new submission drops uBlock into the end of review queue again.. |
|
And where uBlock is into the queue please ? |
|
From gorhill, from today's date: 25 days ago Queue Position: 142 of 143 24 days ago Next Version: 0.9.1.0 23 days ago Next Version: 0.9.1.0 18 days ago Next Version: 0.9.1.0 13 days ago Next Version: 0.9.1.0 11 days ago Next Version: 0.9.1.0 Alex gave an update 5 days ago Next Version: 0.9.1.0 |
|
@AlexVallat Just wanted to get your opinion on something: I don't think we'll be able to have the build system set-up and ready by next release, but there have been quite a few changes/improvements to uBlock since the most recent one. I think it might be a good idea to release a dev-build now for developers to test, so we can be reasonably confident about the next release. What do you think? |
|
@chrisaljoudi Yes, there have been a good set of fixes recently. The only question I would have is whether you plan to merge in @gorhill's changes on his fork for the next release or not. If so, it would be worth doing that before releasing the build. We're still only at 112 of 196 in the queue, so I don't see the AMO version being updated any time soon. |
|
@AlexVallat I've tried to adopt all changes that are fixes. There quite a few that are "new-feature-oriented", and I've chosen not to adopt those (for now). The popup was getting to the point where it was ridiculously ambiguous and hard to use (too many 'similar' buttons), so for the sake of non-advanced users, I'll be wary of throwing new things in there without deliberation. |
|
@chrisaljoudi In that case, I'd say this was a good time for a dev release, sure. |
|
OMG with this rank, a chance for christmast 2022 ! |
|
For what it is worth, Jorge Villalobos gave an update on the Mozilla blog yesterday. "Most preliminary reviews are being reviewed within 8 weeks." Taking that at face value, it would indicate about four more weeks for review, in contradiction to the trend movement. But there is a caveat. Three weeks ago it was six weeks for preliminary review. So the queue has fallen behind two weeks in three. Another stat, "Most nominations for full review are taking less than 9 weeks to review." Which surprisingly isn't much different. |
|
Good news, 0.9.1.0 has passed review and is now available from AMO. Once 0.9.3.5 is considered released, I'll upload that for review next. |
|
On page AMO says that ublock has been preliminarily reviewed. Is there any information when will be a full review? |
👍 😌 |
|
Looks like 0.9.1.0 has gone live on the Firefox repository. Can we immediately push through a request on the latest stable version, to get it approved asap? (from what I gather the approval process currently takes several weeks so the sooner the request is sent the better) |
ghost
mentioned this issue
|
@AlexVallat Hi! Just released 0.9.3.5 — please do take a look at the release notes and let me know if you have any thoughts. At this point, feel free (I think) to submit 0.9.3.5 for review to AMO. :) |
|
@chrisaljoudi Great, I'll submit 0.9.3.5 now. I had a read through the release notes, which look good, but you put a comment in there about me doing something so that uBlock doesn't need a restart? I'm not sure where that came from, but uBlock never needed a restart to activate, so I think that bit should be removed. |
@AlexVallat I just downgraded to 0.9.3.0 over some reason. Network request log stopped working, adding/removing filters in 'my filters' were having no effect whatsoever and new behavior regarding document blocking (as of 0.9.3.5) was showing. I had to restart firefox to get everything back to normal. |
|
@2vek When upgrading, or even more likely when downgrading, problems can occur when there are differences between frame scripts between the versions, due to Firefox caching behaviour. These can be solved by a restart. Nothing has changed in this regard with 0.9.3.5, but with any luck no further changes to the frame scripts will be needed now. |
There should be some sort of process by which releases are submitted to AMO, ideally as automated as possible. At present, I am the manager for the AMO listing for uBlock, but I suggest that an alternative arrangement might be to create a "uBlock Team" account and have that be the owner, rather than belonging to any one person.
Even if the process for submission must be manual, there still needs to be an agreed process.
I assume we're still happy with Experimental status, and don't want to request a full review until a v1.0 release of some sort?
The text was updated successfully, but these errors were encountered: