View source for Enterprise/Meetings/2011 Aug

= August 2011 Enterprise Working Group Call =

== Call Details ==

The Enterprise Working Group call is scheduled for Thursday, August 4th at 09:00 Pacific (16:00 GMT). Call details will be sent to the Mozilla Enterprise mailing list. To subscribe to this list, please send a request to [mailto:stormy@mozilla.com?Subject=Please%20sign%20me%20up%20for%20the%20Mozilla%20Enterprise%20User%20Working%20Group&body=The%20Mozilla%20Enterprise%20User%20Working%20Group%20is%20a%20place%20for%20enterprise%20developers,%20IT%20staff%20and%20Firefox%20developers%20to%20discuss%20the%20challenges,%20ideas%20and%20best%20practices%20for%20deploying%20Firefox%20in%20the%20enterprise.%0A%0ABecause%20we%20would%20like%20to%20vouch%20for%20members%20in%20order%20to%20ensure%20that%20discussions%20are%20private,%20if%20you%20are%20interested%20in%20joining,%20we%20ask%20you%20to%20fill%20out%20a%20short%20form%20to%20let%20us%20know%20who%20you%20are.%0A%0AName:%0A%0AOrganization:%0A%0AEmail%20address%20(Will%20be%20visible%20to%20other%20participants%20when%20you%20email%20the%20list.):%0A%0AWhy%20are%20you%20interested%20in%20participating%20in%20the%20Mozilla%20Enterprise%20User%20Working%20Group?%20What%20are%20you%20most%20looking%20forward%20to%20discussing? join the mailing list.] Please note that mailing list subscription is moderated, and addition to the list may require verification.

== Agenda ==

* Welcome
* Restarting the Enterprise Working Group
* Call for participants

The meeting theme will be “Rapid Release in a Managed Environment”, and will focus discussion around:

* High-level Overview of Mozilla's Rapid Release
* Effects of Rapid Release on a managed environment 
* Identification of issues facing deployment groups and Mozilla
* Add-on compatibility
* Resources available today to help mitigate impacts
** 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

== Meeting Notes ==

EWG Call, August 4th 2011, 09:00 Pacific Daylight Time

=== Welcome ===

Welcome to the Enterprise Working Group's first planned call. Calls will be held at 0900 Pacific on the first Thursday of every month and will have a theme. Today's theme will be Rapid Release, and the effects of same in a managed environment. Additional participants welcome, and a call for additional participation/referral is requested of EWG members present.

Call participants are asked to mute while listening. The command for muting is *6, the command for unmuting is *7.

=== Participant Introductions ===

The following EWG members from Mozilla attended. To respect the wishes of some members, we have not included non-Mozilla members below. Please feel free to update these minutes to include your name and/or org, as desired.

* Stormy Peters, Mozilla
* Kev Needham, Mozilla
* John O'Duinn, Mozilla
* Christian Legnitto, Mozilla
* Rob Strong, Mozilla
* Asa Dotzler, Mozilla
* Janet Swisher, Mozilla
* Jorge Villabos, Mozilla

=== Rapid Release Overview ===

High level overview of Mozilla Rapid Release was given by Christian Legnitto. Source material is available from the [[RapidRelease]] page (see also the Additional Information section of the meeting agenda), and the overview covered:

* 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 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 beta channel, which is a 6 week qualification period with a larger user base (millions, vs. thousands)
* Benefits of Rapid Release:
** Release dates fixed, known. No more moving targets.
** 12-week qualification period through Aurora and Beta channels
** Stronger commitments to the overall structure
** Easier to plan.

Notes: in course of overview the bugs around efforts to provide a Firefox MSI and GPO were mentioned. Those bugs can be viewed on [https://bugzilla.mozilla.org/ Bugzilla] as follows:
* MSI {{bug|231062}}
* GPO {{bug|267888}}

Additionally, information on current and future planned releases can be found at:
* The [[Releases|Mozilla Releases]] page
* The [http://www.mozilla.com/en-US/firefox/channel/ Mozilla Channel] page
* The [http://blog.mozilla.com/futurereleases/ Future Releases] blog

=== Discussion ===

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 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 />
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 />
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 />
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 />
Reply: Christian Legnitto has committed to improving declarative statements/messaging around what changes taken up in each release.

Question: More info on the standards we are developing to. <br />
Reply: Asa Dotzler identifies the standards that we’re developing to are HTML, CSS, DOM, SVG, ECMA/JavaScript. Increasing support for those supports and some smaller derivatives like WebGL and SVG.

Question: a concern around proxy support and NTLN has found significant impact in his group around resource commitments required to work around NTLN, and would like to understand how we can help mitigate that in-product. <br />
Reply: Asa Dotzler f/Mozilla has asked that more info around specifics of issues we’re not supporting well be added to NTLN bugs and bubble pain points up. Preference is to highlight specifics/pain points in beta phases so we can address/fix. Calling out specific bugs in bugzilla or filing new bugs with use cases that demonstrate problems would be very helpful.

Question: Where are we going? <br />
Reply: Asa Dotzler f/Mozilla outlines data-driven methodology guiding development direction.

Question: One of the main issues with certifying new versions is that it’s not just the organizations EWG members represent, it’s the vendors they work with internally (e.g. SAP, Oracle, JD Edwards, etc.), and outreach to vendors they use who must also certify Firefox. There is a delta between a release and when vendors certify a browser version with a provided app that qualifies for support.

Question: Regressions impact in Enterprise. One of the options available to Enterprise is to stay on older versions until the regression is corrected. With rapid release that becomes very difficult, as there is no security backports as older releases are immediately EOL’d. Difficult to figure out which security patches to apply to older releases.<br />
Reply: John O'duinn f/Mozilla would like anecdotal data around regressions that have forced enterprises to stay on an older version. <br />
Follow-up question: It was outlined that both security and feature changes cause it, and will try to forward more info.<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 />
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 />
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)

=== Meeting close ===

Next meeting will be Thursday, September 8th at 0900 Pacific

== Additional Information ==

This information may be of use to participants, and should be reviewed prior to the meeting.

http://mozilla.github.com/process-releases/draft/development_specifics/img/6_weeks.png

* [https://wiki.mozilla.org/RapidRelease The Rapid Release Cycle] (and [https://wiki.mozilla.org/RapidRelease/Calendar calendar])
* [https://wiki.mozilla.org/Releases Firefox Release Tracking]
* 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)
* 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 add-on compatibility validator] (requires an AMO account)
* 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 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]