Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
Do you think it's better when it suddenly appears on stable at 2017-11-14? I do not.
ma.
On 10/11/17 08:32, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable
- but
I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
Do you think it's better when it suddenly appears on stable at 2017-11-14? I do not.
ma.
Will an older version (either 56 or the ESR version, 52) also be included in Fedora 27 as a separate package?
-Mat
On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:
On 10/11/17 08:32, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable
- but
I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
Do you think it's better when it suddenly appears on stable at 2017-11-14? I do not.
ma.
Will an older version (either 56 or the ESR version, 52) also be included in Fedora 27 as a separate package?
No, we (Red Hat Desktop team) will ship Firefox 57 only as well as Mozilla does. Of course anyone can create/maintain additional Firefox packages (ESR, Developer edition...) for Fedora as I mentioned many times before.
This is also reason why I created this update for testing so early.
ma.
-Mat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, 11 Oct 2017, Martin Stransky wrote:
On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:
On 10/11/17 08:32, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
Do you think it's better when it suddenly appears on stable at 2017-11-14? I do not.
ma.
Will an older version (either 56 or the ESR version, 52) also be included in Fedora 27 as a separate package?
No, we (Red Hat Desktop team) will ship Firefox 57 only as well as Mozilla does. Of course anyone can create/maintain additional Firefox packages (ESR, Developer edition...) for Fedora as I mentioned many times before.
This is also reason why I created this update for testing so early.
The problem is that Fedora 27 is still getting updates from updates-testing at the moment (until the final freeze scheduled for 2017-10-17) so anyone running dnf update on F27 will get Firefox 57 at the moment.
Michael Young
On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:
On 10/11/17 08:32, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable
- but
I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
Do you think it's better when it suddenly appears on stable at 2017-11-14? I do not.
ma.
Will an older version (either 56 or the ESR version, 52) also be included in Fedora 27 as a separate package?
Note: There's also IceCat browser available at Fedora:
https://apps.fedoraproject.org/packages/icecat
ma.
On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
It's *updates*-testing repo and software in it should not be 'planned', but basically 'ready' for Fedora. If you want testing repo for experienced users, use COPR.
On 10/11/2017 03:52 PM, Tomasz Torcz wrote:
On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
It's *updates*-testing repo and software in it should not be 'planned', but basically 'ready' for Fedora. If you want testing repo for experienced users, use COPR.
I don't see it that way. Is that your personal statement or is that written in any Fedora rules? I don't see that at Fedora page [1].
Also, the COPR suffers from some drawbacks - can't easily build from Fedora or other git repo [2].
ma.
[1] https://fedoraproject.org/wiki/QA:Updates_Testing [2] I know it's supposed to work but the work flow is somehow complicated and uneasy and it's broken from time to time (actually right now).
On 10/11/2017 04:00 PM, Martin Stransky wrote:
On 10/11/2017 03:52 PM, Tomasz Torcz wrote:
On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
Yes, I understand there is an annotation NOT to push Fx 57 to stable
- but
I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
It's *updates*-testing repo and software in it should not be 'planned', but basically 'ready' for Fedora. If you want testing repo for experienced users, use COPR.
I don't see it that way. Is that your personal statement or is that written in any Fedora rules? I don't see that at Fedora page [1].
The very first sentence of the page you linked above:
The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora
The point is that your update is not intended to ever make it to the stable update, i.e., it is not "scheduled to be released" for anything. If I understood correctly, you want people to test the beta version and then eventually submit the final release (i.e., not this update) to stable. I don't think that's how the updates-testing repository is supposed to be used. Instead, it should only contain updates that will eventually make it into stable.
Regards, Till
On Wed, Oct 11, 2017 at 10:26 AM Till Hofmann thofmann@fedoraproject.org wrote:
The very first sentence of the page you linked above:
The updates-testing repository, also referred to as Test Updates,
contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora
The point is that your update is not intended to ever make it to the stable update, i.e., it is not "scheduled to be released" for anything. If I understood correctly, you want people to test the beta version and then eventually submit the final release (i.e., not this update) to stable. I don't think that's how the updates-testing repository is supposed to be used. Instead, it should only contain updates that will eventually make it into stable.
Yeah, testing for a package that isn't expected to arrive in the stable stream really belongs in a COPR these days. The updates-testing repo should really be used exclusively as a stopover towards a stable release (with the option to revoke it if it reveals problems).
On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann thofmann@fedoraproject.org wrote:
The very first sentence of the page you linked above:
The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora
The point is that your update is not intended to ever make it to the stable update, i.e., it is not "scheduled to be released" for anything. If I understood correctly, you want people to test the beta version and then eventually submit the final release (i.e., not this update) to stable. I don't think that's how the updates-testing repository is supposed to be used. Instead, it should only contain updates that will eventually make it into stable.
Regards, Till
+1 - Exactly...
On 11 October 2017 at 16:23, Gerald B. Cox gbcox@bzb.us wrote:
On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann thofmann@fedoraproject.org wrote:
The very first sentence of the page you linked above:
The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora
The point is that your update is not intended to ever make it to the stable update, i.e., it is not "scheduled to be released" for anything. If I understood correctly, you want people to test the beta version and then eventually submit the final release (i.e., not this update) to stable. I don't think that's how the updates-testing repository is supposed to be used. Instead, it should only contain updates that will eventually make it into stable.
Regards, Till
+1 - Exactly...
Thought I'd quickly test this being built in a COPR ... but where exactly are you building from?
https://src.fedoraproject.org/rpms/firefox/blob/f27/f/firefox.spec
That shows vesion 56, not 57, and same with rawhide.
I didn't think we could build from a non-fedora-branch git branch for a bodhi update ... that feels ... wrong ...
Is this an intended effect of the "arbitrary branches" for modularity?
This really feels like it breaks the history/audit trail fro what ends up in our repos.
This doesn't even show the branch it came from: https://koji.fedoraproject.org/koji/buildinfo?buildID=981886
Surely stuff that is non-scratch in koji and intended for a Fedora compose should come from a release branch - at least outside of modularity stuff?
On Wed, Oct 11, 2017 at 04:34:52PM +0100, James Hogarth wrote:
On 11 October 2017 at 16:23, Gerald B. Cox gbcox@bzb.us wrote:
On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann <thofmann@fedoraproject.org> wrote: The very first sentence of the page you linked above: The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora The point is that your update is not intended to ever make it to the stable update, i.e., it is not "scheduled to be released" for anything. If I understood correctly, you want people to test the beta version and then eventually submit the final release (i.e., not this update) to stable. I don't think that's how the updates-testing repository is supposed to be used. Instead, it should only contain updates that will eventually make it into stable. Regards, Till +1 - Exactly...Thought I'd quickly test this being built in a COPR ... but where exactly are you building from? https://src.fedoraproject.org/rpms/firefox/blob/f27/f/firefox.spec That shows vesion 56, not 57, and same with rawhide. I didn't think we could build from a non-fedora-branch git branch for a bodhi update ... that feels ... wrong ... Is this an intended effect of the "arbitrary branches" for modularity? This really feels like it breaks the history/audit trail fro what ends up in our repos. This doesn't even show the branch it came from: https://koji.fedoraproject.org/koji/buildinfo?buildID=981886
But it gives the commit which is: https://src.fedoraproject.org/rpms/firefox/c/fd700ad0ae450c4705017e05db7af70... itself part of the stransky-firefox-57 branch: https://src.fedoraproject.org/rpms/firefox/commits/stransky-firefox-57
This behavior is nothing new and is the reason why releng does not allow to delete branches in dist-git.
Pierre
On 11 Oct 2017 4:48 pm, "Pierre-Yves Chibon" pingou@pingoured.fr wrote:
On Wed, Oct 11, 2017 at 04:34:52PM +0100, James Hogarth wrote:
On 11 October 2017 at 16:23, Gerald B. Cox gbcox@bzb.us wrote:
On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann <thofmann@fedoraproject.org> wrote: The very first sentence of the page you linked above: The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched
pre-releases
(after the Bodhi enabling point) and stable releases of Fedora The point is that your update is not intended to ever make it to
the
stable update, i.e., it is not "scheduled to be released" for anything. If I understood correctly, you want people to test the
beta
version and then eventually submit the final release (i.e., not
this
update) to stable. I don't think that's how the updates-testing repository is supposed to be used. Instead, it should only contain updates that will eventually make it into stable. Regards, Till +1 - Exactly...Thought I'd quickly test this being built in a COPR ... but where
exactly
are you building from? https://src.fedoraproject.org/rpms/firefox/blob/f27/f/firefox.spec That shows vesion 56, not 57, and same with rawhide. I didn't think we could build from a non-fedora-branch git branch for a bodhi update ... that feels ... wrong ... Is this an intended effect of the "arbitrary branches" for
modularity?Â
This really feels like it breaks the history/audit trail fro what ends
up
in our repos. This doesn't even show the branch it came from:Â https://koji.fedoraproject.org/koji/buildinfo?buildID=981886
But it gives the commit which is: https://src.fedoraproject.org/rpms/firefox/c/fd700ad0ae450c4705017e05db7af7 09f7ea90f0?branch=stransky-firefox-57 itself part of the stransky-firefox-57 branch: https://src.fedoraproject.org/rpms/firefox/commits/stransky-firefox-57
This behavior is nothing new and is the reason why releng does not allow to delete branches in dist-git.
Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Yes I saw the commit but that is my very point.
I was pretty sure that only scratch builds could be carried out from non release branches but you get something into a compose you needed to merge to master or a release branch.
Otherwise things like releng or proven packagers doing rebuilds for library bumps or similar issues start to go very wrong.
They'd go to do a patch or release bump in the branch and boom... versioning screwed.
As I said I suspect this is a side affect of the modularity arbitrary branching stuff, similar to how as an accident it was possible to do docker container builds from the rpms namespace at first.
It'd be good to get confirmation from releng or FESCo on the intended behaviour as this feels wrong...
On Wed, Oct 11, 2017 at 10:07:44PM +0100, James Hogarth wrote:
Yes I saw the commit but that is my very point. I was pretty sure that only scratch builds could be carried out from non release branches but you get something into a compose you needed to merge to master or a release branch.Â
I am also pretty sure this didn't change, since koji does not have the ability to know in which branch a commit is, it takes a url to a git repo and that's about it.
Pierre
On Wed, Oct 11, 2017 at 7:00 AM, Martin Stransky stransky@redhat.com wrote:
It's *updates*-testing repo and software in it should not be 'planned',
but basically 'ready' for Fedora. If you want testing repo for experienced users, use COPR.
I don't see it that way. Is that your personal statement or is that written in any Fedora rules? I don't see that at Fedora page [1].
Also, the COPR suffers from some drawbacks - can't easily build from Fedora or other git repo [2].
ma.
[1] https://fedoraproject.org/wiki/QA:Updates_Testing [2] I know it's supposed to work but the work flow is somehow complicated and uneasy and it's broken from time to time (actually right now).
Martin, this is what is stated at the very top of the doc you referenced: "The *updates-testing* repository https://fedoraproject.org/wiki/Repositories#updates-testing, also referred to as *Test Updates*, contains updates scheduled to be released for Branched https://fedoraproject.org/wiki/Releases/Branched pre-releases (after the Bodhi enabling point https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling) and stable releases of Fedora. User testing and feedback provided via Bodhi http://bodhi.fedoraproject.org, on the test https://admin.fedoraproject.org/mailman/listinfo/test mailing list and the relevant Bugzilla http://bugzilla.redhat.com is vital to ensure that good updates are released quickly and bad ones kept away from release."
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
On Wed, 2017-10-11 at 07:53 -0700, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 7:00 AM, Martin Stransky stransky@redhat.com wrote:
It's *updates*-testing repo and software in it should not be 'planned',
but basically 'ready' for Fedora. If you want testing repo for experienced users, use COPR.
I don't see it that way. Is that your personal statement or is that written in any Fedora rules? I don't see that at Fedora page [1].
Also, the COPR suffers from some drawbacks - can't easily build from Fedora or other git repo [2].
ma.
[1] https://fedoraproject.org/wiki/QA:Updates_Testing [2] I know it's supposed to work but the work flow is somehow complicated and uneasy and it's broken from time to time (actually right now).
Martin, this is what is stated at the very top of the doc you referenced: "The *updates-testing* repository https://fedoraproject.org/wiki/Repositories#updates-testing, also referred to as *Test Updates*, contains updates scheduled to be released for Branched https://fedoraproject.org/wiki/Releases/Branched pre-releases (after the Bodhi enabling point https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling) and stable releases of Fedora. User testing and feedback provided via Bodhi http://bodhi.fedoraproject.org, on the test https://admin.fedoraproject.org/mailman/listinfo/test mailing list and the relevant Bugzilla http://bugzilla.redhat.com is vital to ensure that good updates are released quickly and bad ones kept away from release."
It's worth noting that page isn't really a policy page, it's just an 'informational' page. It's not officially maintained by anyone in control of the update process, or anything. The text was probably just written by a single person, describing the process as they understand it (it may well have been me). I wouldn't rely excessively strongly on a literal reading of the text as if it were the word of law.
The main official policy page regarding updates is:
https://fedoraproject.org/wiki/Updates_Policy
that page *is* locked to drive-by edits and *is* controlled by (IIRC) FESCo in their role as maintainers of the update process. It doesn't really have any rules, right now, about how updates-testing is to be used, but this seems like an omission.
FWIW, my own belief is similar to yours and sgallagh's: updates-testing is really only intended for packages you believe there is at least a decent chance will be ready to be pushed stable. It's not really intended for sending out packages you have no intention of pushing stable. But this does seem to be a slightly unusual case, at least reading between the lines. Perhaps if Firefox 57 is a sufficiently significant update that it needs special handling, exactly how this is to be done (for all supported releases) should be discussed and arranged with FPC and/or FESCo?
On Wed, Oct 11, 2017 at 9:58 AM, Adam Williamson <adamwill@fedoraproject.org
wrote:
On Wed, 2017-10-11 at 07:53 -0700, Gerald B. Cox wrote:
<snip> > Martin, this is what is stated at the very top of the doc you referenced: > "The *updates-testing* repository <snip>
It's worth noting that page isn't really a policy page, it's just an 'informational' page. It's not officially maintained by anyone in control of the update process, or anything. The text was probably just written by a single person, describing the process as they understand it (it may well have been me). I wouldn't rely excessively strongly on a literal reading of the text as if it were the word of law.
That's fine, but Martin referenced it and I just pointed out the plain reading - which is updates there are intended to be pushed to stable.
The main official policy page regarding updates is:
https://fedoraproject.org/wiki/Updates_Policy
that page *is* locked to drive-by edits and *is* controlled by (IIRC) FESCo in their role as maintainers of the update process. It doesn't really have any rules, right now, about how updates-testing is to be used, but this seems like an omission.
I agree, if that page is the policy, it is an omission and needs to be corrected.
FWIW, my own belief is similar to yours and sgallagh's: updates-testing is really only intended for packages you believe there is at least a decent chance will be ready to be pushed stable. It's not really intended for sending out packages you have no intention of pushing stable. But this does seem to be a slightly unusual case, at least reading between the lines. Perhaps if Firefox 57 is a sufficiently significant update that it needs special handling, exactly how this is to be done (for all supported releases) should be discussed and arranged with FPC and/or FESCo?
Well, the problem is that in Fx 57 many extensions will stop working. A few extensions which I use have been modified in the last few days, and many others probably won't be released until the last minute. Many people have updates-testing enabled automatically to tests and report on software. They aren't expected BETA software to be there. That is the point. Software that is not intended to be pushed to STABLE belongs in RAWHIDE. While apparently it isn't written officially anywhere doesn't mean that people should start using updates-testing in that manner. As I mentioned above, if that is the case, why do we need RAWHIDE.
As far as Fx 57 being a special case, it isn't. In fact, if anything due to the extension breakage it should be handled with an abundance of caution - which means don't do anything which would case someone to accidentally install it.
It's extremely easy to install Fx from RAWHIDE by using koji. There is no reason to put it in updates-testing.
This is just sending the wrong message and inviting people to start populating updates-testing with RAWHIDE software - and I can't imagine why anyone would want that.
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
On Wed, Oct 11, 2017 at 1:05 PM Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
I think Gerald's position is overstating it. Upstream's definition of what is "beta" or "stable" is informative but not definitive.
However, in this particular case, the maintainer has stated that this version of the package is *not* intended to actually go to the stable Fedora repository, which says to me that it should not be in the updates-testing stream at all. The point of u-t is to be a last-chance check on the quality before it goes out to all users. It's not intended to be a prototyping location; that's one of COPR's jobs.
On Wed, Oct 11, 2017 at 10:24 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Oct 11, 2017 at 1:05 PM Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
I think Gerald's position is overstating it. Upstream's definition of what is "beta" or "stable" is informative but not definitive.
However, in this particular case, the maintainer has stated that this version of the package is *not* intended to actually go to the stable Fedora repository, which says to me that it should not be in the updates-testing stream at all. The point of u-t is to be a last-chance check on the quality before it goes out to all users. It's not intended to be a prototyping location; that's one of COPR's jobs.
You need to read my entire statement in context. That is not what I meant. As I replied to Heiko:
"My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing."
In this instance, I believe that RAWHIDE would be appropriate - since it not so much a prototype as a BETA release of a single package which is being released within a month. Something like a test release of KDE/GNOME which is comprised of multiple packages would be ideal for COPR - but a Fx BETA COPR would be an excellent idea also.
On Wed, Oct 11, 2017 at 1:37 PM Gerald B. Cox gbcox@bzb.us wrote:
You need to read my entire statement in context. That is not what I meant. As I replied to Heiko:
"My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing."
In this instance, I believe that RAWHIDE would be appropriate - since it not so much a prototype as a BETA release of a single package which is being released within a month. Something like a test release of KDE/GNOME which is comprised of multiple packages would be ideal for COPR - but a Fx BETA COPR would be an excellent idea also.
Actually, I'm not sure if it belongs in Rawhide either, but it's closer. The purpose of Rawhide is actually *integration*, not prototyping. Prereleases are permissible in Rawhide when it is known that this package may require coordinating other updates (such as updating to a new release of a language interpreter or a desktop environment), but in general the goal should be that Rawhide be kept reasonably stable and not treated as a free-for-all playground. In this particular case, I can see an argument here in that we probably want to have a place to work out any incompatibilities with extensions that are packaged in Fedora, but I'm not sure how many of those there are.
On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
As Adam mentioned apparently this isn't the "Official Policy".
My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing.
On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
As Adam mentioned apparently this isn't the "Official Policy".
My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing.
I think there's a bit misunderstanding here. Some parts of the FF57 update are going to be in stable as is (if the testing goes well). That includes the CSD patch [1].
The package may not be finished yet but the FF57 is almost done and 99% of the code is going to be shipped to stable. This is not a completely different version, it may got some bugfixes but what you see is what you will almost get as stable update at Nov 14.
I'm sure the package is almost done so I don't take your argument about "completely different" package.
Due to the radical change in extension handlings and also needs to test the CSD patch [1] which I'd like to include in stable package I decided to put the FF57 to testing as early as possible. This is really a special case.
I believed that the update-testing repository is intended for testing and it's used by power users who can handle that, exclude the package from testing if needed, downgrade broken package and so on.
I'm surprised that people use updates-testing for stable/production machines, have problem with handling the update and act like newbies. If you can't handle that, don't use that. Fedora is really a bleeding edge so don't complain you get new software with new features - even as testing only :)
Also, I think your expectation about dramatic change of new extension availability for FF57 last month before the final release is false.
ma.
On 11 October 2017 at 15:08, Martin Stransky stransky@redhat.com wrote:
On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
As Adam mentioned apparently this isn't the "Official Policy".
My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing.
I think there's a bit misunderstanding here. Some parts of the FF57 update are going to be in stable as is (if the testing goes well). That includes the CSD patch [1].
There are several misunderstandings here but they all stem from a core problem which an old Mozilla quote covers:
Surprise is the opposite of engagement. [1]
It is something we forget a lot.. but is a reason why older maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would make sure that a heads up email about a major version change goes out.
If you put out a heads up that "tomorrow I will be pushing Firefox 57BETA into updates-testing" you could have given people heads up and would have also learned from someone that updates-testing is on for everyone in the post-branch world. While in this case it probably would not have affected your decision, in other cases it might have made it clearer that you needed to do so after a different time. It would have also queued in people to either skip updates or know why their workflow died.
In either case, people would be better informed.
[1] https://opensource.com/business/10/3/five-questions-about-building-community...
On Wed, 2017-10-11 at 15:42 -0400, Stephen John Smoogen wrote:
On 11 October 2017 at 15:08, Martin Stransky stransky@redhat.com wrote:
On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
As Adam mentioned apparently this isn't the "Official Policy".
My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing.
I think there's a bit misunderstanding here. Some parts of the FF57 update are going to be in stable as is (if the testing goes well). That includes the CSD patch [1].
There are several misunderstandings here but they all stem from a core problem which an old Mozilla quote covers:
Surprise is the opposite of engagement. [1]
It is something we forget a lot.. but is a reason why older maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would make sure that a heads up email about a major version change goes out.
If you put out a heads up that "tomorrow I will be pushing Firefox 57BETA into updates-testing" you could have given people heads up and would have also learned from someone that updates-testing is on for everyone in the post-branch world. While in this case it probably would not have affected your decision, in other cases it might have made it clearer that you needed to do so after a different time. It would have also queued in people to either skip updates or know why their workflow died.
In either case, people would be better informed.
Agreed. It is true that in general people using updates-testing should more or less know what they're doing, but they're not necessarily expecting surprises like this. And as smooge says, updates-testing is enabled by default in Branched releases (so, F27 at present); anyone running F27 Beta will get this package as soon as it reaches the mirrors.
I think Harald really has a point that the potentially disruptive nature of the changes in 57 should mean that, if anything, we go *slower* in pushing it out to our users, not *faster*. Unless it includes vital security fixes we can't backport, I don't think there's necessarily a reason we need to jump all over this and try to get it out on release day; why not wait a bit while providing a way for early adopters to try it out if they'd like to?
Note that there is an alternative to both u-t and COPR; you can do scratch builds in Koji, or do real builds but don't actually submit them to updates-testing , and either provide a repo with those builds yourself, or just write a blog post or something explaining which packages people should pull from Koji if they want to test...
On Wed, Oct 11, 2017 at 12:52:11PM -0700, Adam Williamson wrote:
On Wed, 2017-10-11 at 15:42 -0400, Stephen John Smoogen wrote:
On 11 October 2017 at 15:08, Martin Stransky stransky@redhat.com wrote:
On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams ml@fedora-blog.de wrote:
Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
By definition BETA software is never intended to be pushed to stable. Fx 57 is BETA. When the STABLE version is released, then it can go into updates-testing. Not before. Again, that is the purpose of RAWHIDE.
Does this mean it's also not allowed to push packaged git-snapshots of a software to updates-testing because they are unreleased and potentially unstable?
As Adam mentioned apparently this isn't the "Official Policy".
My opinion however is common sense dictates that you don't put anything in updates-testing unless you intend to push that software to stable. If you want people to test out experimental software, put it in RAWHIDE. If it's a git-snapshot and your INTENT is to push it to stable (for example, you're fixing a bug) then that is OK for updates-testing.
In this instance, there is no intent to push Fx 57 BETA to stable. That's why it does't belong in update-testing.
I think there's a bit misunderstanding here. Some parts of the FF57 update are going to be in stable as is (if the testing goes well). That includes the CSD patch [1].
There are several misunderstandings here but they all stem from a core problem which an old Mozilla quote covers:
Surprise is the opposite of engagement. [1]
It is something we forget a lot.. but is a reason why older maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would make sure that a heads up email about a major version change goes out.
If you put out a heads up that "tomorrow I will be pushing Firefox 57BETA into updates-testing" you could have given people heads up and would have also learned from someone that updates-testing is on for everyone in the post-branch world. While in this case it probably would not have affected your decision, in other cases it might have made it clearer that you needed to do so after a different time. It would have also queued in people to either skip updates or know why their workflow died.
In either case, people would be better informed.
Agreed. It is true that in general people using updates-testing should more or less know what they're doing, but they're not necessarily expecting surprises like this. And as smooge says, updates-testing is enabled by default in Branched releases (so, F27 at present); anyone running F27 Beta will get this package as soon as it reaches the mirrors.
OTOH, let's consider two points: one, FF57 is disruptive, and two, FF57 will be released as an update in Fedora when Mozilla make the release, as specified by our policy for FF updates. In the light of this, it seems reasonable to push FF57 to updates-testing right now, the sooner the better.
I don't get the whole kerfuffle about FF57 being beta: F27 is in beta now too, and it's the time to test what will be in the relased version, and using a pre-release of a package seems to be a better way to do this than using some old version that will be soon replaced. If we had a different updates policy for Firefox in Fedora, things would be different, but we don't.
Zbyszek
I think Harald really has a point that the potentially disruptive nature of the changes in 57 should mean that, if anything, we go *slower* in pushing it out to our users, not *faster*. Unless it includes vital security fixes we can't backport, I don't think there's necessarily a reason we need to jump all over this and try to get it out on release day; why not wait a bit while providing a way for early adopters to try it out if they'd like to?
Note that there is an alternative to both u-t and COPR; you can do scratch builds in Koji, or do real builds but don't actually submit them to updates-testing , and either provide a repo with those builds yourself, or just write a blog post or something explaining which packages people should pull from Koji if they want to test... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, 2017-10-11 at 20:58 +0000, Zbigniew Jędrzejewski-Szmek wrote:
OTOH, let's consider two points: one, FF57 is disruptive, and two, FF57 will be released as an update in Fedora when Mozilla make the release, as specified by our policy for FF updates.
Uh, what policy is that? AFAICS Firefox does not have a specific update policy. It's also not listed as having any exceptions at: https://fedoraproject.org/wiki/Updates_Policy#Exceptions .
AIUI we usually send updates to newer Firefox versions out for stable releases under the 'needed to get security fixes out' clause. But that doesn't mean we *must* ship every new version as an update immediately.
In the light of this, it seems reasonable to push FF57 to updates-testing right now, the sooner the better.
I don't get the whole kerfuffle about FF57 being beta: F27 is in beta now too, and it's the time to test what will be in the relased version, and using a pre-release of a package seems to be a better way to do this than using some old version that will be soon replaced. If we had a different updates policy for Firefox in Fedora, things would be different, but we don't.
I don't care about it being in beta. I *do* care about this being an unusual approach to shipping a major Firefox change which wasn't really discussed or even notified about in advance, and which involves sending a package to updates-testing which is clearly not destined for stable. If the package of the beta Firefox was actually intended to go to stable Fedora, and that was in line with the update policy, that would be a different case.
On 10/11/2017 10:58 PM, Zbigniew Jędrzejewski-Szmek wrote:
I don't get the whole kerfuffle about FF57 being beta: F27 is in beta now too, and it's the time to test what will be in the relased version, and using a pre-release of a package seems to be a better way to do this than using some old version that will be soon replaced. If we had a different updates policy for Firefox in Fedora, things would be different, but we don't.
FF57 was also pushed to F26 updates-testing. F26 is not beta but a stable release. I have updates-testing enabled on my main machine to find unexpected package breakages and give feedback about them, which is the whole purpose of updates-testing. If this breaks my main web browser (which could have been expected), I'll just disable updates-testing again. This means less testing of updates, which a lot of people (rightfully) complain about anyway. That's why I think such an update should not go into a stable release's updates-testing.
Actually, as a regular desktop user, I'd be surprised if I got the FF57 with a regular update without upgrading to the latest Fedora release. I don't think FF57 should be in F26 at all.
Regards, Till
On Thu, Oct 12, 2017 at 11:22:52AM +0200, Till Hofmann wrote:
Actually, as a regular desktop user, I'd be surprised if I got the FF57 with a regular update without upgrading to the latest Fedora release. I don't think FF57 should be in F26 at all.
Looking at the updates in bodhi, F26 was release with firefox-52, so you already upgraded a few times :)
On my side, I do like having the latest firefox, also on my old F25.
Pierre
On 10/12/2017 11:32 AM, Pierre-Yves Chibon wrote:
On Thu, Oct 12, 2017 at 11:22:52AM +0200, Till Hofmann wrote:
Actually, as a regular desktop user, I'd be surprised if I got the FF57 with a regular update without upgrading to the latest Fedora release. I don't think FF57 should be in F26 at all.
Looking at the updates in bodhi, F26 was release with firefox-52, so you already upgraded a few times :)
Yes, but that wasn't branded as all-new, better-than-ever Firefox (which it is), that intentionally breaks stuff which is directly visible by the end-user. An update that breaks the majority of extensions is very hard to sell for a stable release, as much as I love the new Firefox.
From an admin POV, this will result in lots of users complaining about their broken browsers, and probably at the wrong time, because not scheduled by the admin.
Also, as someone else has already mentioned in this thread, this is not really in line with the updates policy. I'm not saying we shouldn't receive updates for Firefox, but I think it should get an exception, so everyone actually knows when and why Firefox gets (or doesn't get) updates.
On my side, I do like having the latest firefox, also on my old F25.
Me too, but I don't like my boss complaining about his broken web browser.
Regards, Till
On 10/12/2017 02:54 AM, Till Hofmann wrote:
Yes, but that wasn't branded as all-new, better-than-ever Firefox (which it is), that intentionally breaks stuff which is directly visible by the end-user. An update that breaks the majority of extensions is very hard to sell for a stable release, as much as I love the new Firefox.
Special-casing a normal Firefox release would be a bad idea as they don't receive security backports. Switching Fedora to ESR-only would be the only safe way to accomplish this.
(this is unrelated to whether it should have been pushed as Beta)
On Thu, 2017-10-12 at 10:16 -0700, Thomas Daede wrote:
On 10/12/2017 02:54 AM, Till Hofmann wrote:
Yes, but that wasn't branded as all-new, better-than-ever Firefox (which it is), that intentionally breaks stuff which is directly visible by the end-user. An update that breaks the majority of extensions is very hard to sell for a stable release, as much as I love the new Firefox.
Special-casing a normal Firefox release would be a bad idea as they don't receive security backports. Switching Fedora to ESR-only would be the only safe way to accomplish this.
I think that may not realistically be possible, though, as 56 is not being made an ESR, AFAICT, and it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
However, I don't think this means we MUST ship 57. Talking about 'security backports' in the abstract is all well and good, but no-one even seems to have stated yet that there *are* any important security fixes in 57. Even if there are, we *can* look at the feasibility of backporting them ourselves (or in co-ordination with other distributors, who may well be in the same position as us). It's something we do for many other packages, after all; it's not impossible.
On Thu, Oct 12, 2017 at 10:52:52AM -0700, Adam Williamson wrote:
However, I don't think this means we MUST ship 57. Talking about 'security backports' in the abstract is all well and good, but no-one even seems to have stated yet that there *are* any important security fixes in 57. Even if there are, we *can* look at the feasibility of backporting them ourselves (or in co-ordination with other distributors, who may well be in the same position as us). It's something we do for many other packages, after all; it's not impossible.
Also we might be able to forward-port patches from the latest ESR.
----- Mail original ----- De: "Matthew Miller"
Also we might be able to forward-port patches from the latest ESR.
Though that would not be overly nice to upstream. They took the pain of creating, documenting and supporting two specific update streams to coordinate this change, I'm quite sure they would be very cross with Fedora if it invented some sort of mongrel update path at the last minute (besides how would it work for extensions, they rely on the Firefox version having a specific meaning, are we going to requalify all the existing extension universe?).
If Fedora is getting cold feet at the last minute the best solution would be to package ESR separately and make it available for people that don't really want to be "First". It's probable Mozilla will use the next ESR branching for similar invasive changes anyway now it's been set up.
And yes downgrading from current to ESR is going to cause breakage, but it's a bit late to change gears without breakage one way or another. Consistent breakage with upstream is way better than Fedora-specific breakage
At least, IMHO
Regards,
On Thu, Oct 12, 2017 at 11:42 AM, nicolas.mailhot@laposte.net wrote:
If Fedora is getting cold feet at the last minute the best solution would be to package ESR separately and make it available for people that don't really want to be "First". It's probable Mozilla will use the next ESR branching for similar invasive changes anyway now it's been set up.
And yes downgrading from current to ESR is going to cause breakage, but it's a bit late to change gears without breakage one way or another. Consistent breakage with upstream is way better than Fedora-specific breakage
This thread has changed from my original intent. The reported issue was
using the updates-testing process as a vehicle for testing software not intended to be pushed to stable. I opened a FESCo ticket on the issue here: https://pagure.io/fesco/issue/1782
Adam has opened a FESCo ticket on a separate topic, regarding delaying the release of Fx 57 in Fedora. That ticket is here: https://pagure.io/fesco/issue/1783
Let''s limit this thread to the topic of updates-testing.
If people want to discuss the rationale and impact of delaying Fx 57 in Fedora, please open another topic.
Not trying to be argumentative, but at least for me multiple topics in the same thread cause a loss of focus on the reported issue.
Also I would be *very* surprised if network or website operators that rely on stuff Mozilla is obsoleting didn't start testing for ESR in the user-agent to adopt specific behaviour, if not this year then next one's when Mozilla kills plugins (Yes they're not supposed to. When did that stop them? Especially inside corporation networks or on internal websites.)
That would leave any Firefox Fedora user in a very bad spot, since the test is unlikely to take "ESR-but-not-really" cases into account
On Thu, 2017-10-12 at 20:42 +0200, nicolas.mailhot@laposte.net wrote:
If Fedora is getting cold feet at the last minute
I'd suggest that this is an inaccurate characterization of the issue. I don't believe that 'Fedora' as an entity had even *considered* this situation until the start of this thread. It's not a case that we'd considered and specifically committed to delivering Firefox 57 shortly after release and are now changing our minds; I don't believe anyone outside of Firefox enthusiasts and the package maintainer were even aware there was an issue to discuss.
De: "Adam Williamson"
I don't believe anyone outside of Firefox enthusiasts and the package maintainer were even aware there was an issue to discuss.
The last 2 or 3 Firefox releases have been adding warnings (and ramping them up) in the Firefox extension panel.
I even had a specific presentation @work on Firefox ESR and what it means in terms of compatibility breakage a few months ago, even though we are not an IT company and would be classified as extremely conservative, not too FLOSS-friendly, late to change and sold out to Microsoft on the desktop by outsiders (the reality is much more nuanced and we have a large Firefox deployment internally). God knows our desktop people learnt to anticipate browser breakage after years of trying to standardize on IE, before giving up and authorizing Firefox too.
On Thu, 2017-10-12 at 21:22 +0200, nicolas.mailhot@laposte.net wrote:
De: "Adam Williamson"
I don't believe anyone outside of Firefox enthusiasts and the package maintainer were even aware there was an issue to discuss.
The last 2 or 3 Firefox releases have been adding warnings (and ramping them up) in the Firefox extension panel.
...which you really have no reason to look at unless you're doing something specific in it, in which case you're focusing on that specific thing.
Looking at it right now, the extensions which aren't compatible with F57 have a yellow 'LEGACY' tag on them, but that's all. Clicking on it takes you to a page with an explanation, but I only just discovered that; it's not obvious and there's no explanation on the addons page itself of what 'LEGACY' means.
I even had a specific presentation @work on Firefox ESR and what it means in terms of compatibility breakage a few months ago, even though we are not an IT company and would be classified as extremely conservative, not too FLOSS-friendly, late to change and sold out to Microsoft on the desktop by outsiders (the reality is much more nuanced and we have a large Firefox deployment internally). God knows our desktop people learnt to anticipate browser breakage after years of trying to standardize on IE, before giving up and authorizing Firefox too.
Yes, but we're a *distributor*. It's our job to mediate change for our users, not to just pass it along and wash our hands of it by saying upstream was telling them about it.
----- Mail original ----- De: "Adam Williamson"
Yes, but we're a *distributor*. It's our job to mediate change for our users, not to just pass it along and wash our hands of it by saying upstream was telling them about it.
Sure, and Fedora had the choice of - shipping Firefox - shipping Firefox ESR - shipping Firefox and Firefox ESR
And the good time to make this choice was at ESR branching, and Mozilla communicated a very detailed roadmap beforehand to help distributors and anyone else that ships a desktop that includes Firefox to make the best choice for their users. It is already communicating on the changes that will occur at the next branch point next year BTW.
We understand the concept of branching points at Fedora, right? Maybe there needs to be less focus on new development models and how to enable various non-free binaries or non-free cloud services, and more thought about the classical release engineering actual big software projects use, more thought about the browser which is the central part of any internet-oriented desktop (yes that was cheap on my part but really, people should take a break and get some perspective, focus is good but self absorption is not, it only took me 5 years in start up + some more desintoxication time to learn it, the first person one is overselling to is always oneself).
Kind regards,
On Thu, 2017-10-12 at 22:37 +0200, nicolas.mailhot@laposte.net wrote:
----- Mail original ----- De: "Adam Williamson"
Yes, but we're a *distributor*. It's our job to mediate change for our users, not to just pass it along and wash our hands of it by saying upstream was telling them about it.
Sure, and Fedora had the choice of
- shipping Firefox
- shipping Firefox ESR
- shipping Firefox and Firefox ESR
And the good time to make this choice was at ESR branching, and Mozilla communicated a very detailed roadmap beforehand to help distributors and anyone else that ships a desktop that includes Firefox to make the best choice for their users. It is already communicating on the changes that will occur at the next branch point next year BTW.
You may well have a point, but the fact is, that didn't happen, and we don't have a time machine handy. So it's a good note for the future, but it doesn't really help us resolve this current situation. We still have choices about what we can *actually* do *right now* given that we didn't do what you suggested.
On 10/12/2017 10:52 AM, Adam Williamson wrote:
I think that may not realistically be possible, though, as 56 is not being made an ESR, AFAICT, and it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
I should note that there are also backwards incompatible profile changes from 57 to 56.
Backporting security fixes is definitely an option. I don't know of any current security fixes that need to be backported (and because 57 isn't released yet, severe ones will be backported to 56 point releases by upstream), but if you lock F26 or F27 to 56, you'll have to be backporting for 6 months or a year, respectively.
On Thu, 12 Oct 2017, Adam Williamson wrote:
it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
Ouch.
Is now a good time to think about how we could try to avoid getting into a similar situation again in the future?
I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?
Another option could be to ship Fedora 27 with a Firefox 57 prerelease version. This will stop breakage of extensions 2 weeks after Fedora 27 ships (and shipped extensions can be moved to web extension version).
On 13 Oct 2017 12:31 pm, "Peter Oliver" < lists.fedoraproject.org@mavit.org.uk> wrote:
On Thu, 12 Oct 2017, Adam Williamson wrote:
it sounds like downgrading from 56 to 52
(the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
Ouch.
Is now a good time to think about how we could try to avoid getting into a similar situation again in the future?
I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?
-- Peter Oliver _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 10/13/2017 01:29 PM, Peter Oliver wrote:
On Thu, 12 Oct 2017, Adam Williamson wrote:
it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
Ouch.
Is now a good time to think about how we could try to avoid getting into a similar situation again in the future?
I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/).%C2%A0 For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?
Fedora can certainly ship ESR line but nobody wants to package/maintain it.
ma.
On Fri, Oct 13, 2017 at 02:21:42PM +0200, Martin Stransky wrote:
On 10/13/2017 01:29 PM, Peter Oliver wrote:
On Thu, 12 Oct 2017, Adam Williamson wrote:
it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
Ouch.
Is now a good time to think about how we could try to avoid getting into a similar situation again in the future?
I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/).%C2%A0 For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?
Fedora can certainly ship ESR line but nobody wants to package/maintain it.
... and nobody even seems to want to use it :)
I think that we cannot ignore or escape the fact that we can't hold back Firefox updates. Firefox 57 seems _very_ nice, but even if it wasn't, we just don't have the manpower to hold onto old Firefox versions for a long time. Lifetime of Fedora 27 is 13 or 14 months after the final release of FF57, and by the end of that period FF56 is going to be quite dated, and FF52 ESR even more so.
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model, or trying to find alternatives that work with FF57+. Personally, I now have µBlock Origin, Gnome Shell Integration, and uMatrix as a replacement for noScript, and that covers my basic needs. The rest I can live without. I'd encourage everybody else to make similar reckoning, and identify the missing _essential_ extensions, and concentrate on them.
Zbyszek
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model,
My understanding is that the new API lacks capabilities needed to make some extensions possible. Mozilla may or may not reimplement some of these functionalities in the future, but, for the time being, there’s little that the authors of such extensions can do.
On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote:
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model,
My understanding is that the new API lacks capabilities needed to make some extensions possible. Mozilla may or may not reimplement some of these functionalities in the future, but, for the time being, there’s little that the authors of such extensions can do.
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
Zbyszek
On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote:
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
So lets do a little review of the things I have installed in one of my firefox instances that aren't currently firefox 57 compatible... This is after I've dumped some rarely used things that I decided were unlikely to get an update.
Cookie Monster
Seemed to have been removed from AMO and no obvious replacement.
Download Manager (S3)
Author reports it can't be ported due to lack of required APIs and the same presumably applies to the various similar extensions none of which show any sign of being ported. There are bugs open with mozilla for providing a toolbar API for this but they're not saying much other than "on the roadmap" which could mean anything.
Extension List Dumper 2
Last update in January, no sign of an update or of an obvious replacement but only used occasionally.
NoScript
Supposedly getting a five-to-midnight fix and other options are available if that doesn't happen.
NoSquint Plus
Last update yesterday but no mention of WE plans on AMO page but Zoom Page WE is possible replacement.
pdfit
Ancient and only in use because the (better) extension I used to use to save as PDF stopped working. Will likely replace with screenshots once that has "whole page" mode working.
Saved Password Editor
Needs new APIs which are supposedly in the works but won't be available for 57 at least.
Tab Groups
Author has stated (in a long rant) that he is not going to port to WE and that in any case the APIs will probably always be too limited for it to be possible.
View Cookies
Last updated nearly two years ago with no signs of life and no obvious replacement.
Tom
On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote:
On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote:
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
So lets do a little review of the things I have installed in one of my firefox instances that aren't currently firefox 57 compatible... This is after I've dumped some rarely used things that I decided were unlikely to get an update.
Cookie Monster
Seemed to have been removed from AMO and no obvious replacement.
I use(d) Self Destructing Cookies, but the page for that one says it's not being rewritten as a webextension and will be abandoned:
https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/
"This add-on is no longer maintained. It is incompatible with Firefox 55+ and this will never change. Also, it will not be rewritten as a WebExtension."
https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ seems to be a new webextension along the same lines, I don't know how good / safe it is or whether it does what you wanted from Cookie Monster.
NoSquint Plus
Last update yesterday but no mention of WE plans on AMO page but Zoom Page WE is possible replacement.
I use this one too, it's useful for sites that don't play well with hidpi, though those are becoming less common now. I imagine it may be important for older / vision-impaired users, though.
Tab Groups
Author has stated (in a long rant) that he is not going to port to WE and that in any case the APIs will probably always be too limited for it to be possible.
As this was previously a Firefox feature and the excuse when removing it was "don't worry, it'll be available as an extension" this seems like a rather important one!
On 13/10/17 16:48, Adam Williamson wrote:
On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote:
Cookie Monster
Seemed to have been removed from AMO and no obvious replacement.I use(d) Self Destructing Cookies, but the page for that one says it's not being rewritten as a webextension and will be abandoned:
https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/
"This add-on is no longer maintained. It is incompatible with Firefox 55+ and this will never change. Also, it will not be rewritten as a WebExtension."
https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ seems to be a new webextension along the same lines, I don't know how good / safe it is or whether it does what you wanted from Cookie Monster.
Yes it's not quite the same thing but it might actually be an even better solution so I had my eye on that as a possible replacement.
NoSquint Plus
Last update yesterday but no mention of WE plans on AMO page but Zoom Page WE is possible replacement.I use this one too, it's useful for sites that don't play well with hidpi, though those are becoming less common now. I imagine it may be important for older / vision-impaired users, though.
I mostly just fine that some sites make weirdly small font choices ;-)
I actually use it in text-zoom mode rather than the default full-zoom mode.
Tom
On vendredi 13 octobre 2017 17:48:51 CEST Adam Williamson wrote:
On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote:
On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote:
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
So lets do a little review of the things I have installed in one of my firefox instances that aren't currently firefox 57 compatible... This is after I've dumped some rarely used things that I decided were unlikely to get an update.
Cookie Monster
Seemed to have been removed from AMO and no obvious replacement.
I use(d) Self Destructing Cookies, but the page for that one says it's not being rewritten as a webextension and will be abandoned:
https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/
"This add-on is no longer maintained. It is incompatible with Firefox 55+ and this will never change. Also, it will not be rewritten as a WebExtension."
You can replace SDC with Cookie AutoDelete by Kenny Do:
https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/
It does not support the removal of Localstorage or IndexedDB yet, but the API allowing this are landing in Firefox 58:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1388428 - https://bugzilla.mozilla.org/show_bug.cgi?id=1333050
On Fri, 2017-10-13 at 18:48 +0200, Robert-André Mauchin wrote:
On vendredi 13 octobre 2017 17:48:51 CEST Adam Williamson wrote:
On Fri, 2017-10-13 at 15:56 +0100, Tom Hughes wrote:
On 13/10/17 15:26, Zbigniew Jędrzejewski-Szmek wrote:
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
So lets do a little review of the things I have installed in one of my firefox instances that aren't currently firefox 57 compatible... This is after I've dumped some rarely used things that I decided were unlikely to get an update.
Cookie Monster
Seemed to have been removed from AMO and no obvious replacement.
I use(d) Self Destructing Cookies, but the page for that one says it's not being rewritten as a webextension and will be abandoned:
https://addons.mozilla.org/EN-US/firefox/addon/self-destructing-cookies/
"This add-on is no longer maintained. It is incompatible with Firefox 55+ and this will never change. Also, it will not be rewritten as a WebExtension."
You can replace SDC with Cookie AutoDelete by Kenny Do:
https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/
Uhhh...you mean like the *very next paragraph of my email*, which you cut out, said?
I mean, good grief, maybe finish reading it before hitting Reply next time?
On Fri, 2017-10-13 at 14:26 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote:
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model,
My understanding is that the new API lacks capabilities needed to make some extensions possible. Mozilla may or may not reimplement some of these functionalities in the future, but, for the time being, there’s little that the authors of such extensions can do.
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
Someone's given one example already, here's another:
https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation/
"IMPORTANT: Development of the Calomel SSL Validation addon has been put on hold. Mozilla is disabling XUL and XPCOM in Firefox which means the addon is no longer able to query the current browser tab for the TLS certificate and cipher information."
Sure, you can just manually inspect the details of any given site's certificate and TLS config, but Calomel's icon and grading system made it much easier to notice when some important site had a bad config. :/
On Fri, 2017-10-13 at 09:43 -0700, Adam Williamson wrote:
On Fri, 2017-10-13 at 14:26 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote:
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model,
My understanding is that the new API lacks capabilities needed to make some extensions possible. Mozilla may or may not reimplement some of these functionalities in the future, but, for the time being, there’s little that the authors of such extensions can do.
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
Someone's given one example already, here's another:
https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation /
"IMPORTANT: Development of the Calomel SSL Validation addon has been put on hold. Mozilla is disabling XUL and XPCOM in Firefox which means the addon is no longer able to query the current browser tab for the TLS certificate and cipher information."
Sure, you can just manually inspect the details of any given site's certificate and TLS config, but Calomel's icon and grading system made it much easier to notice when some important site had a bad config. :/
Adam not replying just to you but the general thread. What is the point of bringing up all these plugins breakage ? If Mozilla doesn't care, at most you are going to defer the inevitable by what? 2/3 weeks ? You can do the same by deferring your upgrade to Fedora 27 on your own ... or manually downloading the ESR from Mozilla and running that one.
We are Fedora and we are First, even when it is painful IMHO. The only case when it is appropriate to discuss slowing down a project is if there are known security/privacy/whatever vulnerabilities that are going to be addressed very soon upstream anyway.
If the *direction* of the project is under discussion then the only appropriate way is to let the project go and search for a replacement for the default.
In light of this I think any suggestion of slowing down adoption of the new version in F27 is misplaced.
Simo.
On Oct 13, 2017 19:00, "Simo Sorce" simo@redhat.com wrote:
We are Fedora and we are First, even when it is painful IMHO.
I count for little in the Fedora community, but this is exactly my opinion in this discussion.
A.
On Fri, 2017-10-13 at 12:58 -0400, Simo Sorce wrote:
On Fri, 2017-10-13 at 09:43 -0700, Adam Williamson wrote:
On Fri, 2017-10-13 at 14:26 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote:
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model,
My understanding is that the new API lacks capabilities needed to make some extensions possible. Mozilla may or may not reimplement some of these functionalities in the future, but, for the time being, there’s little that the authors of such extensions can do.
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
Someone's given one example already, here's another:
https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation /
"IMPORTANT: Development of the Calomel SSL Validation addon has been put on hold. Mozilla is disabling XUL and XPCOM in Firefox which means the addon is no longer able to query the current browser tab for the TLS certificate and cipher information."
Sure, you can just manually inspect the details of any given site's certificate and TLS config, but Calomel's icon and grading system made it much easier to notice when some important site had a bad config. :/
Adam not replying just to you but the general thread. What is the point of bringing up all these plugins breakage ?
Zbigniew specifically asked for examples.
On Fri, Oct 13, 2017 at 12:05 PM, Adam Williamson < adamwill@fedoraproject.org> wrote:
On Fri, 2017-10-13 at 12:58 -0400, Simo Sorce wrote:
On Fri, 2017-10-13 at 09:43 -0700, Adam Williamson wrote:
On Fri, 2017-10-13 at 14:26 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Oct 13, 2017 at 02:55:37PM +0100, Peter Oliver wrote:
On Fri, 13 Oct 2017, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model,
Adam not replying just to you but the general thread. What is the point of bringing up all these plugins breakage ?
Zbigniew specifically asked for examples.
I posted this in the other thread, but will repost here:
https://blog.mozilla.org/addons/2015/08/21/the-future-of- developing-firefox-add-ons/
https://blog.mozilla.org/addons/2017/02/16/the-road-to- firefox-57-compatibility-milestones/
https://arewewebextensionsyet.com/
The above are good links to familiarize yourself with what is going on with Fx.
Yes, some extensions are not being ported... but many are.
The nice thing now is that many chrome excellent chrome extensions will now be available to Fx users because they will be easier to modify, for example the excellent Checker Plus extensions for GMail, Google Calendar and Drive. Those are available NOW and have been for some time.
Conversely developers are now interested in making some Fx extensions available for Chrome, for example DownloadThemAll
People who are frustrated LastPass isn't yet a webextension (don't worry, LogMeIn willl meet the deadline) can also checkout Bitwarden... it's available now, and as a plus is GPLv3 - I've been using it for about a month and decided to switch from LastPass, because IMO it's better. People who are interested in SpeedDial, try out the excellent: New Tab Tools Those who want adblockers... there is uBlock Origin
Those are just a few examples. This isn't Fx Apocalypse - it's an opportunity to discover a whole new world of extensions and enjoy a revived, multi-threaded much improved Fx.
Yes, change is hard and people resist it. That is human nature - but as the saying goes... "The train is leaving the station... get onboard, or get left behind.'"
Not trying to be confrontational or upset anybody, but that is the reality. Mozilla isn't going to go backward and change their strategy... ain't gonna happen.
2017-10-13 16:26 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl:
Sure, that's what everybody knows. But without going from generalities to details of a specific extension, we're just speculating idly.
Here's another one: https://addons.mozilla.org/en-US/firefox/addon/advanced-locationbar/
"Warning! This extension will stop work in Firefox 57+ since this version of the browser supports WebExtensions API only. It is not possible to implement this extension using WebExtensions API."
Same holds for the alternative https://addons.mozilla.org/en-US/firefox/addon/locationbar%C2%B2/
- Thomas
On Fri, Oct 13, 2017 at 01:14:50PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
All the energy devoted to this thread would imho be better spent on trying to encourage the authors of popular extensions to update to the new model, or trying to find alternatives that work with FF57+. Personally, I now have µBlock Origin, Gnome Shell Integration, and uMatrix as a replacement for noScript, and that covers my basic needs. The rest I can live without. I'd encourage everybody else to make similar reckoning, and identify the missing _essential_ extensions, and concentrate on them.
+1
Although some extensions are hopeless, as pointed out earlier in the thread. I maintain a small extension to toggle proxy configurations and had to completely rewrite it to support webextensions and even though it still carries the same name/branding, it is a completely different extension regarding its features (still better than letting users down). I feel sorry for people who put a lot of effort maintaining their extensions who now have to either abandon them and their users or completely rewrite their extensions.
On Fri, Oct 13, 2017 at 6:04 PM, Athos Ribeiro athoscribeiro@gmail.com wrote:
I maintain a small extension to toggle proxy configurations […]
Hi Athos, Does noturno support proxy authentication by any chance ;) ?
Please use the thread Fx 57 Release Issues. This discussion isn't about the use of the updates-testing repository for non-update software.
On Fri, Oct 13, 2017 at 8:23 AM, Alexander Ploumistos < alex.ploumistos@gmail.com> wrote:
On Fri, Oct 13, 2017 at 6:04 PM, Athos Ribeiro athoscribeiro@gmail.com wrote:
I maintain a small extension to toggle proxy configurations […]
Hi Athos, Does noturno support proxy authentication by any chance ;) ? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, Oct 13, 2017 at 6:31 PM, Gerald B. Cox gbcox@bzb.us wrote:
Please use the thread Fx 57 Release Issues. This discussion isn't about the use of the updates-testing repository for non-update software.
Sure, sorry for the digression.
On Fri, 2017-10-13 at 12:29 +0100, Peter Oliver wrote:
On Thu, 12 Oct 2017, Adam Williamson wrote:
it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
Ouch.
Is now a good time to think about how we could try to avoid getting into a similar situation again in the future?
I see that Firefox ESR releases are supported for one year plus twelve weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?
We've chosen not to ship ESR in the past, AIUI, because we think our target audiences generally prefer to get the main Firefox release stream, they don't want the ESR stream. We could change that decision, of course. I don't personally think a one-off ouch-y event like this would entirely justify such a change, but it'd be interesting to know if the Quantum stuff means a series of such ouch-y events might potentially be coming to the main release stream.
Adam, can you please use the other thread. This discussion has gotten way off topic. The other thread I opened is Fx 57 Release Issues.
Thanks!
On Fri, Oct 13, 2017 at 8:40 AM, Adam Williamson <adamwill@fedoraproject.org
wrote:
On Fri, 2017-10-13 at 12:29 +0100, Peter Oliver wrote:
On Thu, 12 Oct 2017, Adam Williamson wrote:
it sounds like downgrading from 56 to 52 (the most recent ESR), aside from the epoch bump it'd require on our side, is not straightforward (it seems there were profile changes between 56 and 52).
Ouch.
Is now a good time to think about how we could try to avoid getting into
a similar situation again in the future?
I see that Firefox ESR releases are supported for one year plus twelve
weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/). For Fedora 27, would it be safer to include Firefox 57 and 58, but then stick with Firefox 59 ESR from March onwards?
We've chosen not to ship ESR in the past, AIUI, because we think our target audiences generally prefer to get the main Firefox release stream, they don't want the ESR stream. We could change that decision, of course. I don't personally think a one-off ouch-y event like this would entirely justify such a change, but it'd be interesting to know if the Quantum stuff means a series of such ouch-y events might potentially be coming to the main release stream. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, 2017-10-13 at 08:44 -0700, Gerald B. Cox wrote:
Adam, can you please use the other thread. This discussion has gotten way off topic. The other thread I opened is Fx 57 Release Issues.
I think that ship sailed long ago, I'm afraid. I can't really 'move' a reply to the other thread, email doesn't work that way.
On 10/13/2017 10:40 AM, Adam Williamson wrote:
We've chosen not to ship ESR in the past, AIUI, because we think our target audiences generally prefer to get the main Firefox release stream, they don't want the ESR stream. We could change that decision, of course. I don't personally think a one-off ouch-y event like this would entirely justify such a change, but it'd be interesting to know if the Quantum stuff means a series of such ouch-y events might potentially be coming to the main release stream.
Shipping ESR will just lead to fragmentation of the user base. Some will create a copr with the latest version.
Is everyone being over-dramatic (per usual)?
Does this update break the entire browser?
Could I make plenty more rhetorical questions?
If we're going to suggest shipping ESR we might as well stop shipping the latest kernel, too.
I can't believe I replied to this thread. :(
On Fri, 2017-10-13 at 10:47 -0500, Michael Cronenworth wrote:
Is everyone being over-dramatic (per usual)?
To take that personally for a minute, well, no, I don't believe I've been over-dramatic at all. I've never suggested anything besides 'maybe we should take a look at whether shipping Firefox 57 as fast as we usually ship updates is the best idea', and that's all the FESCo ticket I filed says. (My specific suggestion so far has been not to ship it for a couple of weeks after upstream releases it, to see just how common complaints turn out to be in widespread public use).
It's not my fault that people seem to have taken this off in weird directions like "can we switch to ESR forever?!" or "can we maintain FF 56 until Fedora 27 EOL?!"
Does this update break the entire browser?
No, it's more akin to the switch from Gnome 2 to Gnome 3: lots of changes all over the place, old trusted features gone, replacements not totally there and in any case different requiring user adaptation.
Which all means our release planning is too focused on Gnome and not enough thought is put into the roadmap of major non-Gnome desktop apps such as Firefox or Libreoffice. I'd argue that this kind of Firefox change is way more impacting for our users than the latest gnome settings redesign.
Too late to switch to ESR now, the best outcome would be to make FF57 a major feature of F27 (since it will be), ship it (even as prerelease) from day 1 and pretend that was always what our release engineering intended to do.
Regards,
On 10/13/2017 07:11 PM, nicolas.mailhot@laposte.net wrote:
Which all means our release planning is too focused on Gnome and not enough thought is put into the roadmap of major non-Gnome desktop apps such as Firefox or Libreoffice. I'd argue that this kind of Firefox change is way more impacting for our users than the latest gnome settings redesign.
Definitely. Fedora in danger to become (or already is) Gnome's and Firefox's "puppet".
This needs to change. Fedora should be in service of its users not arbitrary upstreams or their package maintainers.
Too late to switch to ESR now, the best outcome would be to make FF57 a major feature of F27 (since it will be), ship it (even as prerelease) from day 1 and pretend that was always what our release engineering intended to do.
IMHO, it would be reasonable and common sense to either postpone F27 until FF57 has become stable or to revert the firefox change.
Ralf
On Sun, 15 Oct 2017 15:35:56 +0200, you wrote:
IMHO, it would be reasonable and common sense to either postpone F27 until FF57 has become stable or to revert the firefox change.
Except FF57 is stable (at least no one so far is complaining about it being otherwise).
For those who use its plugins then there may be an issue (depending on how many do a last minute update vs. can't/won't be udated) but that day of reckoning is coming sooner or later unless they choose to never update Firefox again.
On Sun, Oct 15, 2017 at 7:47 AM, Gerald Henriksen ghenriks@gmail.com wrote:
Except FF57 is stable (at least no one so far is complaining about it being otherwise).
For those who use its plugins then there may be an issue (depending on how many do a last minute update vs. can't/won't be udated) but that day of reckoning is coming sooner or later unless they choose to never update Firefox again.
Completely agree. Fx 57 is an extremely important release for Mozilla and they've done and excellent job communicating the changes and getting the release ready. The main thing people are going to notice is the improved performance and cleaner interface.
For those of you who were concerned about LastPass:
https://www.engadget.com/2017/10/13/lastpass-beta-firefox-57-webextension/
The beta version is available now - The final version will be ready when the browser arrives on November 14th.
As I mentioned earlier, for those who want to use a GPLv3 product, check out Bitwarden:
https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/
On Sun, 2017-10-15 at 09:59 -0700, Gerald B. Cox wrote:
For those of you who were concerned about LastPass:
https://www.engadget.com/2017/10/13/lastpass-beta-firefox-57-webextension/
The beta version is available now - The final version will be ready when the browser arrives on November 14th.
As I mentioned earlier, for those who want to use a GPLv3 product, check out Bitwarden:
https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/
BTW, thanks for the tip on this, I'm trying it out now. Though I'm a bit unsure whether 'F/OSS but backed by Microsoft and written all in Microsoft things and hosted on Azure' wins out over 'not-F/OSS' in my book :P
On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
people are going to notice is the improved performance and cleaner interface.
Yes! Because of this thread's original message, I pulled 57 into F26 eager to try it out (on $dayjob workstation). Now I want it at $home workstation. Is there a COPR or some alternative for early testers in F26 now that the update has been withdrawn? I'd do more looking on my own, but our corporate web proxy right now is eating kittens and other helpless creatures and might as well be unplugged for all the good it's doing me.
On 16 October 2017 at 14:58, John Florian john@doubledog.org wrote:
On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
people are going to notice is the improved performance and cleaner interface.
Yes! Because of this thread's original message, I pulled 57 into F26 eager to try it out (on $dayjob workstation). Now I want it at $home workstation. Is there a COPR or some alternative for early testers in F26 now that the update has been withdrawn? I'd do more looking on my own, but our corporate web proxy right now is eating kittens and other helpless creatures and might as well be unplugged for all the good it's doing me.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I'm just writing up a Fedora Magazine article covering this at present ;)
I have a build running in a COPR now, and the article will include details of that.
Since we *are* on the development list where COPR is normal ... ;)
Up till the point FF57 rejoins updates-testing in F26 sometime in November I'm going to track commits to the F27/rawhide FF57 packages and build them for F25 and F26 for early testing.
https://copr.fedorainfracloud.org/coprs/jhogarth/firefox57/
The builds are completing at present ... once they have completed you'll be able to pick it up there.
On Mon, 2017-10-16 at 15:03 +0100, James Hogarth wrote:
On 16 October 2017 at 14:58, John Florian john@doubledog.org wrote:
On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
people are going to notice is the improved performance and cleaner interface.
Yes! Because of this thread's original message, I pulled 57 into F26 eager to try it out (on $dayjob workstation). Now I want it at $home workstation. Is there a COPR or some alternative for early testers in F26 now that the update has been withdrawn? I'd do more looking on my own, but our corporate web proxy right now is eating kittens and other helpless creatures and might as well be unplugged for all the good it's doing me. _______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I'm just writing up a Fedora Magazine article covering this at present ;)
I have a build running in a COPR now, and the article will include details of that.
Since we *are* on the development list where COPR is normal ... ;)
Up till the point FF57 rejoins updates-testing in F26 sometime in November I'm going to track commits to the F27/rawhide FF57 packages and build them for F25 and F26 for early testing.
https://copr.fedorainfracloud.org/coprs/jhogarth/firefox57/
The builds are completing at present ... once they have completed you'll be able to pick it up there.
Excellent! Thank you for doing this.
On lundi 16 octobre 2017 15:58:32 CEST John Florian wrote:
On Sun, 2017-10-15 at 09:23 -0700, Gerald B. Cox wrote:
people are going to notice is the improved performance and cleaner
interface.
Yes! Because of this thread's original message, I pulled 57 into F26 eager to try it out (on $dayjob workstation). Now I want it at $home workstation. Is there a COPR or some alternative for early testers in F26 now that the update has been withdrawn? I'd do more looking on my own, but our corporate web proxy right now is eating kittens and other helpless creatures and might as well be unplugged for all the good it's doing me.
If you don't mind living on the edge, I provide weekly builds of Firefox Nightly (58) here: https://copr.fedorainfracloud.org/coprs/eclipseo/firefox-nightly/
It contains all the Fedora specific patches, including Martin's CSD patch. It's stable, at least for me.
On 10/11/2017 09:42 PM, Stephen John Smoogen wrote:
[....]
It is something we forget a lot.. but is a reason why older maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would make sure that a heads up email about a major version change goes out.
If you put out a heads up that "tomorrow I will be pushing Firefox 57BETA into updates-testing" you could have given people heads up and would have also learned from someone that updates-testing is on for everyone in the post-branch world. While in this case it probably would not have affected your decision, in other cases it might have made it clearer that you needed to do so after a different time. It would have also queued in people to either skip updates or know why their workflow died.
I agree with you here, I should post the head up. I agree I underestimated that and I'm sorry for it.
ma.
In either case, people would be better informed.
[1] https://opensource.com/business/10/3/five-questions-about-building-community...
On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky stransky@redhat.com wrote:
I'm surprised that people use updates-testing for stable/production machines, have problem with handling the update and act like newbies. If you can't handle that, don't use that. Fedora is really a bleeding edge so don't complain you get new software with new features - even as testing only :)
Where is Matthew Miller when you need him? No one said anything about
using updates-testing for stable/productioin machines. And the fact that you're implying that Fedora itself is bleeding edge and not really suited for production raises a huge red flag.
i have no doubt when this whole situation is reviewed logical minds will prevail, but in the meantime you've taken advantage of a loophole. Congratulations.
On Wed, 2017-10-11 at 17:13 -0700, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky stransky@redhat.com wrote:
I'm surprised that people use updates-testing for stable/production machines, have problem with handling the update and act like newbies. If you can't handle that, don't use that. Fedora is really a bleeding edge so don't complain you get new software with new features - even as testing only :)
Where is Matthew Miller when you need him? No one said anything about
using updates-testing for stable/productioin machines. And the fact that you're implying that Fedora itself is bleeding edge and not really suited for production raises a huge red flag.
i have no doubt when this whole situation is reviewed logical minds will prevail, but in the meantime you've taken advantage of a loophole. Congratulations.
I think you're getting a bit needlessly confrontational at this point. The issue's been sufficiently well raised now. Let's try to move forward productively from here...
On Wed, Oct 11, 2017 at 5:36 PM, Adam Williamson <adamwill@fedoraproject.org
wrote:
On Wed, 2017-10-11 at 17:13 -0700, Gerald B. Cox wrote:
On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky stransky@redhat.com wrote:
I'm surprised that people use updates-testing for stable/production machines, have problem with handling the update and act like newbies.
If
you can't handle that, don't use that. Fedora is really a bleeding
edge so
don't complain you get new software with new features - even as testing only :)
Where is Matthew Miller when you need him? No one said anything about
using updates-testing for stable/productioin machines. And the fact that you're implying that Fedora itself is bleeding edge and not really suited for production raises a huge red flag.
i have no doubt when this whole situation is reviewed logical minds will prevail, but in the meantime you've taken advantage of a loophole. Congratulations.
I think you're getting a bit needlessly confrontational at this point. The issue's been sufficiently well raised now. Let's try to move forward productively from here...
Exactly what is confrontational? I quoted his statement. Yes, the issue has been raised. Martin is apparently going to keep it in updates-testing because that's what he wants to do. It may or may not be reviewed - and he took advantage of a loophole. Since when is in confrontational to summarize facts?
Am 11.10.2017 um 21:08 schrieb Martin Stransky:
I believed that the update-testing repository is intended for testing and it's used by power users who can handle that, exclude the package from testing if needed, downgrade broken package and so on.
I'm surprised that people use updates-testing for stable/production machines, have problem with handling the update and act like newbies. If you can't handle that, don't use that. Fedora is really a bleeding edge so don't complain you get new software with new features - even as testing only :)
Also, I think your expectation about dramatic change of new extension availability for FF57 last month before the final release is false.
"dramatic change" seems a bit ... dramatic ;-) However I know at least one somewhat popular addon (NoScript) which is planned to have a release just before the Firefox 27 release (https://noscript.net/getit#devel). So the push to F26 updates-testing really hurts some users more than necessary.
Other than that I think Fedora maintainers worked hard to get away from the perception of "unstable/bleeding edge distro" to a more "provides new software but still reliable".
I think this is not about "having updates-testing enabled and not being able to handle breakage" - in the end all the complaints came from users who can "handle" the breakage. I'd like to echo other's concerns that I treat "updates-testing" very similar to "updates" just with the additional caveat that it might be a tad bit less tested.
Please let's keep it that way.
fs
On Thursday, 12 October 2017 at 10:44, Felix Schwarz wrote: [...]
However I know at least one somewhat popular addon (NoScript) which is planned to have a release just before the Firefox 27 release (https://noscript.net/getit#devel). So the push to F26 updates-testing really hurts some users more than necessary.
NoScript developers offer this useful tip on the page you linked:
IMPORTANT: if you're using Firefox 57 you'll need to open about:config and turn the extensions.legacy.enabled preference to true, otherwise the browser will refuse to install Noscript. Furthermore, you need a "blueish" Firefox, either Firefox Developer Edition or Nightly. The preference trick doesn't work in "orange" Firefox (beta/release). NoScript is currently a Hybrid WebExtension, and therefore won't install on Firefox 57 pre-releases without this trick. Before Firefox 57 is released in the stable channel, a pure WebExtension NoScript will be available an you'll be automatically migrated to it.
*sigh* This indeed means the release in Fedora should be coordinated at least with all Firefox extensions package mainainers. Martin, have you contacted all the extension maintainers directly to coordinate? If not, please do so now.
Regards, Dominik
* Gerald B. Cox [11/10/2017 07:53] :
By definition BETA software is never intended to be pushed to stable.
We've sometimes pushed beta versions of software, usually when that version is more stable than the previous stable release.
I'm all for enforcing rules on what goes to the updates and updates-testing repos but I'ld be happier if they went through the proper channels (FESCo/FPC) rather than made up on the fly.
Emmanuel
On Wed, Oct 11, 2017 at 6:32 AM, Martin Stransky stransky@redhat.com wrote:
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
It's going to be stable in one month. Fx 57 release date is 2017-11-14.
And? My point was that Fx 57 isn't stable now, it's BETA.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
I expect the testing repo is used by experienced users who wish to test software planned for Fedora thus I don't see any problem here.
It is my understanding that is the purpose of RAWHIDE. updates-testing is for software that is intended to be pushed to stable. It isn't for BETA software.
There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.
Do you think it's better when it suddenly appears on stable at 2017-11-14? I do not.
Well, if people want to test, they can use Nightly or RAWHIDE. If people start placing BETA software in updates-testing, why do we need RAWHIDE.
On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose? Fx 57 is BETA, and I was under the impression that BETA software was for RAWHIDE.
Yes, I understand there is an annotation NOT to push Fx 57 to stable - but I thought that was the purpose of updates testing... software there is intended to be tested and pushed to stable.
There are many extensions which aren't yet available for Fx 57 - and we're effectively moving up the timetable by putting it in updates testing.
To be clear here, my intention was to enable early testing of new Firefox 57 release which also includes the CSD patch [1].
If there's no interest for such package I'll pull that out and you can expect regular FF57 update when the time comes. Please speak out at #BZ [2].
And no, I'm not going to create COPR builds for that - it does not contain required NSS/NSPR packages and building from git is broken.
ma.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1399611 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1500806
On 2017-10-11, 14:38 GMT, Martin Stransky wrote:
And no, I'm not going to create COPR builds for that - it does not contain required NSS/NSPR packages and building from git is broken.
I don’t think I want to get immersed into merit of this discussion, but let me just note that:
a) there is no problem to build NSS/NSPR packages in COPR as well,
b) it is possible to build package in COPR from ANY URL of SRPM, which means it could be as well SRPM in koji.
Just my €0.02.
Matěj
In practical terms, FF57 disables all extensions.
I had forgotten how unusable the web has become without NoScript ...
Anyway, I wouldn't advise anyone else to update to this version if you use extensions at all.
Rich.
On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I had forgotten how unusable the web has become without NoScript ...
Have you tested with the latest noscript? 5.1.1 claims to support Fx57 and is in updates-testing, too.
Regards, Dominik
On 10/12/2017 10:48 AM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I had forgotten how unusable the web has become without NoScript ...
Have you tested with the latest noscript? 5.1.1 claims to support Fx57 and is in updates-testing, too.
There's also "extensions.legacy.enabled" pref at about:config which can be flipped:
https://wiki.mozilla.org/Add-ons/Firefox57
ma.
Regards, Dominik
On Thu, Oct 12, 2017 at 10:53:18AM +0200, Martin Stransky wrote:
On 10/12/2017 10:48 AM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I had forgotten how unusable the web has become without NoScript ...
Have you tested with the latest noscript? 5.1.1 claims to support Fx57 and is in updates-testing, too.
There's also "extensions.legacy.enabled" pref at about:config which can be flipped:
It doesn't work in our version of Firefox.
Something to do with whether Firefox is built as a developer version or a beta version.
Rich.
On Thu, Oct 12, 2017 at 10:48:45AM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I had forgotten how unusable the web has become without NoScript ...
Have you tested with the latest noscript? 5.1.1 claims to support Fx57 and is in updates-testing, too.
I didn't even know we shipped extensions in Fedora.
I installed mozilla-noscript-5.1.1-1.fc28.noarch and restarted firefox but it doesn't make any difference. NoScript still shows up as a "Legacy" extension and isn't working.
Is there something you're supposed to do to enable it?
Rich.
On Thursday, 12 October 2017 at 10:56, Richard W.M. Jones wrote:
On Thu, Oct 12, 2017 at 10:48:45AM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I had forgotten how unusable the web has become without NoScript ...
Have you tested with the latest noscript? 5.1.1 claims to support Fx57 and is in updates-testing, too.
I didn't even know we shipped extensions in Fedora.
We do and it's a convenient way to have an extension installed for all users at once.
I installed mozilla-noscript-5.1.1-1.fc28.noarch and restarted firefox but it doesn't make any difference. NoScript still shows up as a "Legacy" extension and isn't working.
Is there something you're supposed to do to enable it?
The about:config switch doesn't work in beta/release versions, as you have discovered already. I'll update to 5.1.2 in F27 as soon as it's released.
Regards, Dominik
On 10/12/2017 01:08 AM, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I think thats a bit overstated. I'm running FF57 here with a bunch of extensions that work with it.
It's true that a number of older extensions will not work.
One thing to look at is to go to the extensions home page and look at the very bottom and see if it has a developer channel. Enabling that will sometimes give you a webextension supported version.
I had forgotten how unusable the web has become without NoScript ...
Might give uMatrix a try?
Anyway, I wouldn't advise anyone else to update to this version if you use extensions at all.
Indeed, but note that you might want to upgrade and check your extensions and see what your state is before Nov...
kevin
On Thu, 12 Oct 2017 09:05:33 -0700 Kevin Fenzi kevin@scrye.com wrote:
On 10/12/2017 01:08 AM, Richard W.M. Jones wrote:
In practical terms, FF57 disables all extensions.
I think thats a bit overstated. I'm running FF57 here with a bunch of extensions that work with it.
I agree with this. I run nightly in addition to the fedora version of firefox, and I have found that some of my dearly loved extensions have new versions. And where not, someone has often written a replacement for the new interface. I found such extensions by searching in the add-ons pages at Mozilla. My main lack is that I haven't found a replacement for antvideodownloader or dwhelper yet (video downloaders).
That said, from reading Mozilla forums, it seems that the new web extension interface is more restricted than the XUL interface it is replacing, and certain functionality can't be replaced. Which means that some current XUL extensions can never be recreated as a web extension. The reason this was done is to enhance security. So, it is the old trade-off; security versus ease of use.
I don't understand the losses well enough to know whether some of the things I like to do in firefox with extensions can be replicated or not. I've thought about keeping an older version of firefox around that can use the old extensions for special cases.
Mozilla has been warning about this for over a year in their development version (nightly), so it shouldn't come as a surprise.
On Thu, 2017-10-12 at 11:22 -0700, stan wrote:
Mozilla has been warning about this for over a year in their development version (nightly), so it shouldn't come as a surprise.
For me at least, it is a surprise. I had not heard about this until this mailing list thread.
I'm sure it's not a surprise for people who are specifically interested in Mozilla / Firefox news; it does seem to have been discussed there for a long them. But I'm not. I just use Firefox. I don't run betas, I don't run nightlies, I don't read Firefox-specific news sites etc. I doubt I'm particularly unusual among Fedora users.
On Thu, Oct 12, 2017 at 09:05:33AM -0700, Kevin Fenzi wrote:
It's true that a number of older extensions will not work.
Well, looking at the most popular extensions:
https://addons.mozilla.org/en-GB/firefox/extensions/?sort=users
hardly any of them are parked as "compatible with firefox 57+". I'm counting 5/20 on the first page linked there, and 4/20 on the first page of the highest rated extensions.
So I stand by my slightly modified claim that installing this update will disable most of your extensions.
Rich.
On Thu, 2017-10-12 at 19:54 +0100, Richard W.M. Jones wrote:
On Thu, Oct 12, 2017 at 09:05:33AM -0700, Kevin Fenzi wrote:
It's true that a number of older extensions will not work.
Well, looking at the most popular extensions:
https://addons.mozilla.org/en-GB/firefox/extensions/?sort=users
hardly any of them are parked as "compatible with firefox 57+". I'm counting 5/20 on the first page linked there, and 4/20 on the first page of the highest rated extensions.
So I stand by my slightly modified claim that installing this update will disable most of your extensions.
I think you might be surprised how many *new* WebExtension alternatives are available, but they are not yet popular when competing against the *old* standbys. IMHO, Mozilla could have done better with epoch weighting, displaying the legacy tags far earlier -- those are really quite recent. I was also annoyed that I couldn't easily limit my search for non-legacy extensions when using firefox < 57.
I learned about this incompatibility while dealing with an unrelated issue in VimFx several months ago and was sad to learn that extension would not be ported given the differences and the amount of time it would require. I began a panic search for replacements because of how utterly dependent I am on some. I think many popular extensions are going to fall into this category if they're not backed by companies or enthusiasts with lots of time.
So I'm happily testing from u-t now so I can convince myself everything is going to be alright. I'm not going to judge whether this via u-t was correct or not; I've heard great arguments while perched atop of the fence.
On 12/10/17 22:48, John Florian wrote:
On Thu, 2017-10-12 at 19:54 +0100, Richard W.M. Jones wrote:
On Thu, Oct 12, 2017 at 09:05:33AM -0700, Kevin Fenzi wrote:
It's true that a number of older extensions will not work.
Well, looking at the most popular extensions:
https://addons.mozilla.org/en-GB/firefox/extensions/?sort=users
hardly any of them are parked as "compatible with firefox 57+". I'm counting 5/20 on the first page linked there, and 4/20 on the first page of the highest rated extensions.
So I stand by my slightly modified claim that installing this update will disable most of your extensions.
I think you might be surprised how many *new* WebExtension alternatives are available, but they are not yet popular when competing against the *old* standbys. IMHO, Mozilla could have done better with epoch weighting, displaying the legacy tags far earlier -- those are really quite recent. I was also annoyed that I couldn't easily limit my search for non-legacy extensions when using firefox < 57.
I have been actively looking for replacements for the various extensions that I use for the last couple of releases and so far only about 50% or so have anything even vaguely equivalent with only weeks left to be before the extensionpocalypse hits.
The biggest issues are NoScript (which is supposedly coming) and Cookie Monster (which seems to be hopeless) but there are plenty of others.
Tom
On Thu, 2017-10-12 at 22:57 +0100, Tom Hughes wrote:
The biggest issues are NoScript (which is supposedly coming) and Cookie Monster (which seems to be hopeless) but there are plenty of others.
As someone else mentioned, uMatrix is an alternative (in many ways superior) to Noscript, and seems to have a web extension version available.
-
Adam Williamson -
Alessio Ciregia -
Alexander Ploumistos -
Athos Ribeiro -
Dominik 'Rathann' Mierzejewski -
Emmanuel Seyman -
Felix Schwarz -
Gerald B. Cox -
Gerald Henriksen -
Heiko Adams -
James Hogarth -
John Florian -
Kevin Fenzi -
M A Young -
Martin Stransky -
Matthew Miller -
Matěj Cepl -
Michael Cronenworth -
Mátyás Selmeci -
Naheem Zaffar -
nicolas.mailhot＠laposte.net -
Peter Oliver -
Pierre-Yves Chibon -
Ralf Corsepius -
Richard W.M. Jones -
Robert-André Mauchin -
Simo Sorce -
stan -
Stephen Gallagher -
Stephen John Smoogen -
Thomas Daede -
Thomas Moschny -
Till Hofmann -
Tom Hughes -
Tomasz Torcz -
Zbigniew Jędrzejewski-Szmek