canmove, Confirmed users
1,126
edits
Enterprise/Meetings/2011 Aug: Difference between revisions
Jump to navigation
Jump to search
m
Typo fixes
No edit summary |
m (Typo fixes) |
||
| Line 16: | Line 16: | ||
* Effects of Rapid Release on a managed environment | * Effects of Rapid Release on a managed environment | ||
* Identification of issues facing deployment groups and Mozilla | * Identification of issues facing deployment groups and Mozilla | ||
* | * Add-on compatibility | ||
* Resources available today to help mitigate impacts | * Resources available today to help mitigate impacts | ||
** Automated testing/certification of Firefox for a managed environment | ** Automated testing/certification of Firefox for a managed environment | ||
** | ** Add-on verification and compatibility tools/processes | ||
* Longer-term strategies/goals for the Enterprise Working Group | * Longer-term strategies/goals for the Enterprise Working Group | ||
| Line 32: | Line 32: | ||
* Information on [http://blog.mozilla.com/futurereleases/ Future Releases] | * Information on [http://blog.mozilla.com/futurereleases/ Future Releases] | ||
* [https://developer.mozilla.org/en/firefox_6_for_developers Firefox 6 for developers] on the [https://developer.mozilla.org Mozilla Developer Network] (MDN) | * [https://developer.mozilla.org/en/firefox_6_for_developers Firefox 6 for developers] on the [https://developer.mozilla.org Mozilla Developer Network] (MDN) | ||
* AMO [http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/ Rapid Releases | * AMO [http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/ Rapid Releases Add-on compatibility plan] | ||
* Stand-alone [https://addons.mozilla.org/en-US/developers/addon/validate | * Stand-alone [https://addons.mozilla.org/en-US/developers/addon/validate add-on compatibility validator] (requires an AMO account) | ||
* The [https://www.ohloh.net/p/amo-validator AMO validator] project (code) | * The [https://www.ohloh.net/p/amo-validator AMO validator] project (code) | ||
* [http://blog.mozilla.com/addons/2011/06/07/making-compatible-with-firefox-5-and-6/ Making your | * [http://blog.mozilla.com/addons/2011/06/07/making-compatible-with-firefox-5-and-6/ Making your add-on compatible with Firefox 5 and 6] | ||
* Mozilla's [http://quality.mozilla.org/ QA Site] and general information about [http://quality.mozilla.org/teams/automation/ Firefox test automation] | * Mozilla's [http://quality.mozilla.org/ QA Site] and general information about [http://quality.mozilla.org/teams/automation/ Firefox test automation] | ||
| Line 67: | Line 67: | ||
* Mechanics of rapid release | * Mechanics of rapid release | ||
* Overview of rationale behind RR - For FF4 and every version before, development of major version was 1-1.5 years long. During that time market would change and features would be added. Some features were done well in advance of release, and the goal of RR is fewer changes at an increased pace to better keep in time with the evolution of the web. | * Overview of rationale behind RR - For FF4 and every version before, development of major version was 1-1.5 years long. During that time market would change and features would be added. Some features were done well in advance of release, and the goal of RR is fewer changes at an increased pace to better keep in time with the evolution of the web. | ||
* Overview of release cadence, | * Overview of release cadence, with a planned release [http://blog.johnath.com/2011/07/18/every-six-weeks/ every six weeks], with the longest release delta being 12 weeks (one quarter). | ||
* Overview of the Aurora channel, which are nightly builds of what's in the pipe that allow for testing and qualification before being released to the Beta channel. Aurora is string and feature frozen, but changes to those strings and features may change or be removed. Aurora builds live in this channel for 6 weeks, and are then promoted to Beta six weeks prior to release. | * Overview of the Aurora channel, which are nightly builds of what's in the pipe that allow for testing and qualification before being released to the Beta channel. Aurora is string and feature frozen, but changes to those strings and features may change or be removed. Aurora builds live in this channel for 6 weeks, and are then promoted to Beta six weeks prior to release. | ||
* Overview of the beta channel, which is a 6 week qualification period with a larger user base (millions, vs. thousands) | * Overview of the beta channel, which is a 6 week qualification period with a larger user base (millions, vs. thousands) | ||
| Line 88: | Line 88: | ||
Question: Whether MSI or other release mechanisms should be considered for deployment.<br /> | Question: Whether MSI or other release mechanisms should be considered for deployment.<br /> | ||
Reply: Rob Strong f/Mozilla would like to discuss, and should be | Reply: Rob Strong f/Mozilla would like to discuss, and should be contacted in the EWG discussion group or via direct mail (available to list members).<br /> | ||
Follow-up Question: from John f/Mozilla - who does an enterprise know about this new version, how do you physically get it put out on all the machines. Is that it?<br /> | Follow-up Question: from John f/Mozilla - who does an enterprise know about this new version, how do you physically get it put out on all the machines. Is that it?<br /> | ||
Reply: Was asking about deployment mechanisms and software update services to enable enterprises could be used to move more quickly in those processes. Updates through the internet generally don't work because of policy/bandwidth, could manage internally on an server internally. Would like to understand what deployment services orgs are using for deployment, what the preferred mechanisms are, and what their preferences are. (many different approaches) | Reply: Was asking about deployment mechanisms and software update services to enable enterprises could be used to move more quickly in those processes. Updates through the internet generally don't work because of policy/bandwidth, could manage internally on an server internally. Would like to understand what deployment services orgs are using for deployment, what the preferred mechanisms are, and what their preferences are. (many different approaches) | ||
Question: Professional Services groups have customers of their own with lots of solutions ranging from MSI to environments where they don’t control their end user browsers like students. Would like better data around disclosure of what will remain backwards compatible to give them an idea of what apps might be broken with a new release. A positioning statement, statement of intent, would ease fears of things changing all over the place.<br /> | Question: Professional Services groups have customers of their own with lots of solutions ranging from MSI to environments where they don’t control their end user browsers like students. Would like better data around disclosure of what will remain backwards compatible to give them an idea of what apps might be broken with a new release. A positioning statement, statement of intent, would ease fears of things changing all over the place.<br /> | ||
Reply: (multiple Mozilla personnel) General acceptance that Mozilla can improve this information. Information is made available on the [https://developer.mozilla.org Mozilla Developer Network] (MDN) for | Reply: (multiple Mozilla personnel) General acceptance that Mozilla can improve this information. Information is made available on the [https://developer.mozilla.org Mozilla Developer Network] (MDN) for each release (e.g. [https://developer.mozilla.org/en/firefox_6_for_developers Firefox 6 for Developers], [https://developer.mozilla.org/en/firefox_7_for_developers Firefox 7 for Developers], etc.) | ||
Question: Looking for some positional statement on what will change from release to release. <br /> | Question: Looking for some positional statement on what will change from release to release. <br /> | ||
Reply: Christian Legnitto f/Mozilla identifies the smaller changesets, and smaller diffs. Different types of bugs now on short release, however. Binary | Reply: Christian Legnitto f/Mozilla identifies the smaller changesets, and smaller diffs. Different types of bugs now on short release, however. Binary add-on compatibility not guaranteed between major releases. Point releases used to be sec/stability only, now we’re accepting feature/interface changes. Binary components will need recompilation by release (outline 6 week beta delta), and move to js ctypes/away from binary components are strongly encouraged (post links to related info around ctypes, compatibility testing, etc.). Christian gave example of accept-headers bug we backed out in beta because of impact on larger search services, giving us more flexibility in mitigating changes that break stuff. Even though compatibility isn't guaranteed, the expectation is that the changes from 4-5-6-7 will be much smoother than 3.6 to 4. Changesets will be smaller, and Mozilla is documenting those changes which it believe will break things, especially add-ons (see Firefox for Developer links, above).<br /> | ||
Follow-up question: Pushes for official statement again saying everything that Christian just said.<br /> | Follow-up question: Pushes for official statement again saying everything that Christian just said.<br /> | ||
Reply: Christian Legnitto has committed to improving declarative statements/messaging around what changes taken up in each release. | Reply: Christian Legnitto has committed to improving declarative statements/messaging around what changes taken up in each release. | ||
| Line 116: | Line 116: | ||
Reply: Asa Dotzler f/Mozilla posits that most of the regressions are caused by security changes, not feature changes. <br /> | Reply: Asa Dotzler f/Mozilla posits that most of the regressions are caused by security changes, not feature changes. <br /> | ||
Reply: Understand, and it is valid concern, but it still creates an issue, and RR doesn’t really leave the opportunity to stay back on older releases.<br /> | Reply: Understand, and it is valid concern, but it still creates an issue, and RR doesn’t really leave the opportunity to stay back on older releases.<br /> | ||
Follow-up: Even if there’s no regressions/changes, still need to | Follow-up: Even if there’s no regressions/changes, still need to re-certify an application whenever the browser version changes. Big impact is 3rd party vendors who certify browsers consider the version change to be a major change, when the changes are not, but that’s interpretive. Major version number constitutes a major change, and forces re-certification at vendor and deployment level. As a result, optics of versioning hurt and require re-certification<br /> | ||
Question: Rob Strong f/Mozilla asks if members can scrub data and share information around issues they run into, how Fx is used, and where the pain points are. <br /> | Question: Rob Strong f/Mozilla asks if members can scrub data and share information around issues they run into, how Fx is used, and where the pain points are. <br /> | ||
Reply: Some orgs works with clients on Fx 4 & 5 | Reply: Some orgs works with clients on Fx 4 & 5 deployments, and will try to help to anonymize and share information and will provide.<br /> | ||
Question: John O'Duinn f/Mozilla would like to work with EWG members to go over implementation methodologies; Robert Strong f/Mozilla will also discuss w/EWG members and go over deployment methods (which Mozilla will try to publish) | Question: John O'Duinn f/Mozilla would like to work with EWG members to go over implementation methodologies; Robert Strong f/Mozilla will also discuss w/EWG members and go over deployment methods (which Mozilla will try to publish) | ||