Re: Maintaining the en-US dictionary that ships with Mozilla products
Le 29/12/2015 18:23, Ehsan Akhgari a écrit : On 2015-12-28 2:31 PM, Jörg Knobloch wrote: Recently I was browsing some bugs in "Core::Spelling checker" and much to my surprise found four bugs where people complained about wrong or missing words in the en-US dictionary. There were two bugs where people complained about words in the German and the French dictionaries. The German and French bugs were finally closed as "wontfix" and "invalid" and referred back to the respective dictionary maintainers. For French there is a very good a approach: The French dictionaries are maintained via this site: http://www.dicollecte.org/ and imported for distribution with the French version of Firefox. The situation for German is not as good, but there is a maintainer whose work is then turned into an add-on (in fact, sadly, two competing ones). As you have discovered, we don't ship any non-en-US dictionaries with Firefox, so the above is off topic for this mailing list. We do ship dictionaries with Firefox localized builds when their licence allows it. Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Maintaining the en-US dictionary that ships with Mozilla products
Le 02/01/2016 12:07, Jörg Knobloch a écrit : On 2/01/2016 10:53, Jesper Kristensen wrote: The en-US dictionary for localized Firefox was last updated in March 2013 according to https://addons.mozilla.org/da/firefox/addon/united-states-english-spellche/versions/ It is very unfortunate that this add-on maintained by "jooliaan" is so badly out of date. I don't know how to contact the author. I suggest that he synchronise the add-on with the Mozilla maintained en-US dictionary once this has been improved, see below. AFAIK, jooliaan (Giuliano Masseroni) is no longer contributing to the Mozilla project, he was part of the Italian volunteer community. Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing navigator.buildID?
Le 30/10/2016 à 00:34, Nicholas Alexander a écrit : On Sat, Oct 29, 2016 at 7:21 AM, Kohei Yoshino wrote: So the Battery Status API has just been removed, I think now is a good time to think about navigator.buildID again, which bug [1] has been inactive for a whole year. 4 years ago, Firefox 16 removed a minor version number from the user agent string to mitigate fingerprinting [2][3]. However, the build ID unique to each minor version is still exposed via the non-standard navigator.buildID property. Since trackers can easily retrieve build IDs from Mozilla Wiki [4] to map them to minor version numbers, the fix in Firefox 16 was totally meaningless. There were some legitimate use cases on Mozilla properties, for example, warning visitors who are using an outdated Firefox, but those usages have been replaced with the UITour API [5]. A comment in the bug [1] explains that Netflix was also using the build ID to detect a specific playback bug in Firefox, but it's probably not longer relevant. Given that, I believe the buildID property should be removed, or at least made chrome-only. I concur, we shouldn't leak such fine-grained information about the UA to content. For future discussion, my Nightly uses User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Firefox/52.0 but navigator.buildID is 20161015030203, revealing much more than 52.0. As for chrome-only -- I wonder how many consumers there are. about:support, perhaps? Hi, IMO the builID is important for our community of nightly testers that report bug and need to indicate precisely in which build they found a regression, so keeping that information available via about:support and extensions such as Nightly Testers Tools seems valuable for mozilla to me in a chrome context. Regards Pascal -- Pascal Chevrel pascalc on irc://irc.mozilla.org/nightly ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documenting uses of Github at Mozilla
Le 01/10/2014 00:27, Kevin Brosnan a écrit : Not even close with about 10 minutes searching I found * https://github.com/mozilla-b2g * https://github.com/mozilla-services * https://github.com/mozbrick * https://github.com/Mozilla-TWQA * https://github.com/mozillahispano * https://github.com/mozfr Kevin Hi, The last two are the github organizations of our Spanish and French speaking communities. I don't know if Curtis meant Mozilla projects by employees or also projects Mozilla volunteers do. That said, the l10n-drivers team also has a github org were we store scripts and small apps we use in our day to day work: https://github.com/mozilla-l10n/ I don't think the repo list can be complete as we create code all the time which means new repositories get regularily creates, but maybe the purpose should be to list projects that could benefit from external contributions (and in this case, also maybe list projects in our volunteer communities). Cheers Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Breakdown of Firefox full installer
Le 15/10/2014 04:09, Mike Hommey a écrit : On Tue, Oct 14, 2014 at 09:03:30PM -0400, Ehsan Akhgari wrote: Coming from a country with typically slow Internet connections, I strongly disagree. We should absolutely strive to be better than the competition by providing a smaller download size. Only matching the competition should be the minimum bar. :) I'm not saying we shouldn't strive for better, but I'm questioning the fact that download size would be affecting our growth. If the download size of our competitors is not affecting theirs, why would it affect ours? (and again, the premise is an interrogation) Mike Hi Maybe we should take these things into account too?: 1/ A lot of the people I know that have Chrome didn't download it, it came bundled with the computer/flash/antivirus/acrobat/google earth... Downloading is more crucial to us than it is to Google because it is our only distribution channel, that's why I think we need to do better than the competition there. 2/ Maybe Google has better infrastructure than us and can provide better download speed across the globe? I haven't noticed download speed difference between the Chrome and Firefox installers from Paris, but are we sure that out download speed is as efficient as it could be in Kenya, India or China? 3/ Our other big competitors are IE and Safari and they also come bundled with Windows, so no downloading needed either for them Regards, Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
Le 27/01/2015 22:31, Chris Peterson a écrit : On 1/27/15 9:29 AM, Jonas Sicking wrote: We keep telling websites to not use the UA string, however we've so far been very bad at asking them why they use the UA string and then create better alternatives for them. Essentially many websites need to do server-side feature detection in order to determine what version of the website to serve. However we expose *very* few client capabilities in the original HTTP request to a website. Essentially only "supports HTML", which clearly isn't terribly useful. Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. chris Mozilla.org uses UA sniffing to propose the right download process for Firefox to users wisiting our download pages, that seems like a legitimate use of UA sniffing to me :) Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 63 starts August 23
Hi all, On August 23, we will be merging Firefox 63 from mozilla-central to beta for the first time. In order to avoid invalidating the testing we get out of late Nightly and the early Developer Edition builds and to ensure that we can roll out Beta 63 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from August 23 until after the version bump to 64 on September 4th. Some reminders for the soft code freeze period: Do: - Be ready to backout patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team https://wiki.mozilla.org/Release_Management/Release_Process#Nightly_soft_code_freeze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 63 starts August 23
Hello, This is a reminder that the Nightly Soft Freeze is now less than a week away. Please be mindful of any large or risky patches targeting Firefox 63 before the soft freeze begins and we begin merges to the Beta branch. Thanks! Pascal Le 09/08/2018 à 15:18, Pascal Chevrel a écrit : > Hi all, > > On August 23, we will be merging Firefox 63 from mozilla-central to beta > for the first time. In order to avoid invalidating the testing we get > out of late Nightly and the early Developer Edition builds and to ensure > that we can roll out Beta 63 to a wider audience with confidence, we'd > like to ask that any risky changes be avoided from August 23 until after > the version bump to 64 on September 4th. > > Some reminders for the soft code freeze period: > > Do: > - Be ready to backout patches that cause crash spikes, new crashes, > severe regressions > - Monitor new regressions and escalate merge blockers > - Support release management by prioritizing fixing of merge blockers > > Do Not: > - Land a risky patch or a large patch > - Land new features (that affects the current Nightly version) — be > mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can > lead to unexpected CI results > - Flip prefs that enable new Features that were untested in Nightly cycle > - Plan to kick off new experiments that might impact a feature's merge > readiness > > Please let us know if you have any questions/concerns. > > Thanks, > > Release Management Team > > https://wiki.mozilla.org/Release_Management/Release_Process#Nightly_soft_code_freeze > -- Pascal Chevrel Staff Project Manager - Firefox Nightly https://wiki.mozilla.org/Nightly ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 64 starts October 15
Hi all, The soft code freeze period is now over. Regards Pascal Le 10/10/2018 à 17:07, Julien Cristau a écrit : > Hi all, > > On October 15, we will be merging Firefox 64 from mozilla-central to > beta for the first time. In order to avoid invalidating the testing we > get out of late Nightly and the early Developer Edition builds and to > ensure that we can roll out Beta 64 to a wider audience with confidence, > we'd like to ask that any risky changes be avoided from October 15 until > after the version bump to 65 on October 22. Please also be mindful of > any landings late this week or over the weekend: we're shortening the > soft code freeze this cycle to reduce confusion and friction, but that > means we don't have a buffer between the first merge and shipping the > 64.0b1 builds. > > Some reminders for the soft code freeze period: > > Do: > - Be ready to backout patches that cause crash spikes, new crashes, > severe regressions > - Monitor new regressions and escalate merge blockers > - Support release management by prioritizing fixing of merge blockers > > Do Not: > - Land a risky patch or a large patch > - Land new features (that affects the current Nightly version) — be > mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can > lead to unexpected CI results > - Flip prefs that enable new Features that were untested in Nightly cycle > - Plan to kick off new experiments that might impact a feature's merge > readiness > > Please let us know if you have any questions/concerns. > > Thanks, > > Release Management Team > > ___________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > -- Pascal Chevrel Staff Project Manager - Firefox Nightly https://wiki.mozilla.org/Nightly ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 67 starts March 11
Hi all, On March 11, we will be merging Firefox 67 from mozilla-central to beta for the first time. In order to avoid invalidating the testing we get out of late Nightly and the early Developer Edition builds and to ensure that we can roll out Beta 67 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from March 11 until after the version bump to 68 on March 18. Please also be mindful of any landings late this week or over the weekend as there will be very little buffer between the first merge and shipping the 67.0b1 builds. Some reminders for the soft code freeze period: Do: - Be ready to backout patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team -- Pascal Chevrel Firefox Release Manager ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft Code Freeze for Firefox 69 starts July 1st
Hi all, On July 1st, we will be merging Firefox 69 from mozilla-central to beta for the first time. In order to avoid invalidating the testing we get out of late Nightly and the early Developer Edition builds and to ensure that we can roll out Beta 69 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from July 1st until after the version bump to 70 on July 8. Please also be mindful of any landings late this week or over the weekend as there will be very little buffer between the first merge and shipping the 69.0b1 builds. Some reminders for the soft code freeze period: Do: - Be ready to backout patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team -- Pascal Chevrel Firefox Release Manager ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 71, Oct 14
Hi all, We will be merging Firefox 71 from mozilla-central to beta for the first time later today, Oct. 14. In order to avoid invalidating the testing we get out of late Nightly and the early Developer Edition builds and to ensure that we can roll out Beta 71 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Oct. 14 until after the version bump to 72 on Oct 21. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 74 starts February 4
The subject should have been "Soft code freeze for Firefox 74 starts February 4" of course, not 73, sorry for the inconvenience. Pascal Le 04/02/2020 à 14:00, Pascal Chevrel a écrit : > > Hi all, > > With Firefox 73 RC shipping today, we are nearing the end of the > Nightly 74 cycle. > > In order to avoid invalidating the testing we get out of late Nightly > and to ensure that we can roll out Beta 74 to a wider audience with > confidence, we'd like to ask that any risky changes be avoided from > today until after the version bump to 74 on February 10. > > Some reminders for the soft code freeze period: > > Do: > - Be ready to back out patches that cause crash spikes, new crashes, > severe regressions > - Monitor new regressions and escalate merge blockers > - Support release management by prioritizing fixing of merge blockers > > Do Not: > - Land a risky patch or a large patch > - Land new features (that affect the current Nightly version) — be > mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can > lead to > unexpected CI results > - Flip prefs that enable new Features that were untested in the > Nightly cycle > - Plan to kick off new experiments that might impact a feature's merge > readiness > > Please let us know if you have any questions/concerns. > > Thanks, > Pascal & the Release Management team > > -- > Pascal Chevrel > Firefox Release Manager > + Firefox Nightly community management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 73 starts February 4
Hi all, With Firefox 73 RC shipping today, we are nearing the end of the Nightly 74 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 74 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from today until after the version bump to 74 on February 10. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 77 starts April 30
Hi all, With Firefox 76 RC shipping soon, we are nearing the end of the Nightly 77 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 77 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday April 30 until after the version bump to 78 on May 4. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 77 starts April 30
Hello, The Nightly version number increase has landed on mozilla-central and the soft freeze is now complete. Thanks, Pascal Le 27/04/2020 à 11:10, Pascal Chevrel a écrit : > Hi all, > > With Firefox 76 RC shipping soon, we are nearing the end of the Nightly 77 > cycle. > > In order to avoid invalidating the testing we get out of late Nightly and > to ensure that we can roll out Beta 77 to a wider audience with > confidence, > we'd like to ask that any risky changes be avoided from Thursday April 30 > until after the version bump to 78 on May 4. > > Some reminders for the soft code freeze period: > > Do: > - Be ready to back out patches that cause crash spikes, new crashes, > severe > regressions > - Monitor new regressions and escalate merge blockers > - Support release management by prioritizing fixing of merge blockers > > Do Not: > - Land a risky patch or a large patch > - Land new features (that affect the current Nightly version) — be mindful > that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to > unexpected CI results > - Flip prefs that enable new Features that were untested in the Nightly > cycle > - Plan to kick off new experiments that might impact a feature's merge > readiness > > Please let us know if you have any questions/concerns. > > Thanks, > Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 80 starts July 23
Hi all, With Firefox 79 RC shipping soon, we are nearing the end of the Nightly 80 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 80 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday July 23 until after the version bump to 81 on July 27. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management https://fx-trains.herokuapp.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 83 starts October 15
Hi all, With Firefox 82 RC shipping soon, we are nearing the end of the Nightly 83 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 83 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday October 15 until after the version bump to 84 on October 19. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management https://fx-trains.herokuapp.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 84 starts November 12
Hi all, With Firefox 83 RC shipping soon, we are nearing the end of the Nightly 84 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 84 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday November 12 until after the version bump to 85 on November 16. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management https://fx-trains.herokuapp.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 86 starts January 21
Hi all, With Firefox 85 RC shipping soon, we are nearing the end of the Nightly 86 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 86 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday January 21 until after the version bump to 87 on January 25. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 86 starts January 21
Hi all, The last merge from autoland to mozilla-central before the version bump has now happened, so the soft freeze for 86 is over, and development for Firefox 87 is underway. Cheers, Pascal Le 19/01/2021 à 10:25, Pascal Chevrel a écrit : Hi all, With Firefox 85 RC shipping soon, we are nearing the end of the Nightly 86 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 86 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday January 21 until after the version bump to 87 on January 25. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Pascal & the Release Management team -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management -- Pascal Chevrel Firefox Release Manager + Firefox Nightly community management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please upgrade to at least Mercurial 2.5.1
Le 21/02/2013 12:36, Gervase Markham a écrit : On 20/02/13 16:06, Justin Lebar wrote: The client bug that's fixed with the new version of hg is slowly and irreversibly ruining our blame, so I don't think we should wait before upgrading clients. The Mercurial download page: http://mercurial.selenic.com/downloads/ offers 2.5.1 for Mac and Windows, but no Linux packages. Can guidance be provided as to where to get such things for commonly-run versions of Linux? Gerv For Ubuntu, there is a ppa: https://launchpad.net/~mercurial-ppa/+archive/releases Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
