firefox 3.1 and xulrunner 1.9.1 for intrepid/universe

I will add a few things:

7. I told firefox-3.1 to use a copy of the firefox (3.0) user profile (created at the first run) so the risk of breaking the default firefox is null. We did the same last year with firefox-3.0 when firefox 2 was still the default. The advantage is that both versions of firefox could be used at the same time. This will be reverted using the same profile migration UI when 3.1 becomes default.
8. System wide addons and plugins are looked for at the same place as for 3.0, so no need to do any transition.
9. the packaging of 3.1 evolved at the same pace as the 3.0 one, thanks to a lot of Bazaar branch management, so a bug found in one, is almost immediately ported to the other (when it is relevant).

subscribed motu-release. setting to triaged to indicate that everything is available.

Hi,

hm... that way, we'd end up having ff2, ff3 and ff3.1 in the archives for intrepid?

In regards to naming, I've got a suggestion:
How about having one firefox-next package (or firefox-svn or similar), which could generally serve to ship the next upcoming version?

Also, I'd like to hear from motu-sru about the plans for -updates, subscribing them.

Cheers,
   Stefan.

Aren't we removing ff2 from the archive? Anyway, I quite like Stefan's idea however I would propose a name which gives more the idea that this is a development version. Perhaps firefox-unstable, or firefox-snapshot (like for newest gcc, emacs etc.)?

ff2 is indeed to be removed.

This firefox-3.0 / firefox-3.1 is similar to gcc-3.3 / gcc-4.1 / gcc-4.2 / gcc-4.3.The idea is to be able to install one, or the other, or both, depending on the user requirements. In the past, we had firefox-trunk which was for VCS snapshots but here, it's not about snapshots but about milestones. I have 3.0a2 ready, and b1 is not very far ahead. After that, upstream only planed b2 but who knows what could happen.

For snapshots, we have PPAs, which are good enough (except for the missing dbgsym packages which will hopefully be fixed by the LP team). I don't think it's wise to add firefox-snapshot in universe.

i can confirm that firefox-2 will be removed in this cycle. so we could understand this as a deal :).

@firefox-next: people that install firefox-3.1 now, shouldnt end up using firefox-4.0 once that is "-next". the versioning is a good procedure and allows users to decide explicitly what they want.

The whole logic would be to make it (at least somewhat) clear from the very name that this is a development version. I just would like to avoid people using it instead of the regular version expecting it to be stable and mature.
I don't see it as a problem having this being carried from series to series, I do expect that if you fancy the latest and greatest than you won't mind doing it (and if you suddenly do you just install the regular one).

This is clearly identified both in the desktop launcher and in the Help / About dialog.
3.1 is called Shiretoko (3.0 was called Granparadiso) and the icon is a blue planet (not the orange and blue firefox).

Ok, fair enough. I must admit that I wouldn't know about the code names, but assume that the logo be sufficient to serve the purpose (probably combined with a package description stating that it's not the stable version).

Out of interest: How do you plan the transition for jaunty? Drop the ff3 package and add a dummy ff3 to ff3.1 drawing in ff3.1?

Finally, I'm not opposed to having ff3.1 in, but I'd love to hear opinions from motu-sru first.

Cheers,
    Stefan.

@norsetto: there are pros and cons of both ways of doing things. We decided to use this scheme in gutsy - after careful thoughts and even after trying the -trunk/-snapshot thing. There are pros and cons for bot approaches, but it is well understood that we can only provide a seemless and pleasent user-experience when not going the -trunk approach.

 1. users should never be accidentially upgrade from an (almost) stable release to a late alpha
 2. profiles are not interchangable, meaning you cannot switch up and down for major firefox versions without a) forking the profiles and b) risking dataloss if you use the same profile directory. Further, the main browser must not have a profile directory that isn't the same as upstream profile directory. Its a bit lengthy to explain here what we do and why that is lot of easier to do if we use versioned packages and meta packages, but if you want any details ping me on irc.
 3. its not only -trunk. its also -old (like in hardy we didnt have a preview packages, but only a legacy one). All this makes it quite complicated and moving all the bits from package to package is just wasted effort and requires constant conflicts/replaces transitions.

@sispoty: the transition is done through the meta packages. so people that install "firefox" opt-in to be always redirected to the latest stable firefox-x.x package. People that don't install the meta package will not be transitioned, but in the ends thats their decision. Maybe we could introduce two more meta packages called "firefox-edge" and "firefox-legacy" ... that would be similar to the meta package and would allow users to opt-in into either always running the bleedging-edge (firefox-edge) the main browser (firefox) and the old browser (firefox). In case we dont ship anything older than the main browser, we would make the firefox-legacy meta package poiint to the main package (or in case we dont ship a bleeding edge package point firefox-edge to the main browser).

I'm catching up on my bugmail.

I think that an essential pre-requisite to approving this is a commitment
from Canonical to provide security support for it. This is not a package
MOTU can support.

Alexander, thanks, for the insight, seems sane, and I believe you'll know best what firefox users might want in regards to the upgrade path.

Scott: good point. Subscribed motu-swat.@motu-swat: what's your opinion?

Finally, this is a tough decision for me. Personally, I think for intrepid's release it'd be best to go ahead with this plan. However as I stated previosly, I'd like to hear from our stable supporting teams first, if they're happy with it as well. Since Scott raised a good point, I've also subscribed motu-swat, any feedback is welcome.

Why would updates stop after 6 months? You'll be doing the same thing for Jaunty after that anyway... If they will stop after 6 months, should it perhaps be timebombed? Software being unsupportable is also usually a good reason for not releasing with it.

Due to the Mozilla Corp trademark restrictions I believe that only
mozillateam can properly maintain this package and so it should not be
accepted without a commitment from asac to maintain it for the life of the
release (as they are doing for firefox in Hardy).

Looking at the state of the Gutsy Firefox-3.0 package concerns me.

Speaking with motu-sru hat on, I think no-one except guys from mozillateam is able to tell if a SRU proposal is valid or not, new bugfix releases are usually way too complex to weight regression potential in a sane way. This is probably one of the reasons Firefox falls under micro-release exceptions (https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions), so I think Scott's proposal to ask Alexander (or mozillateam) to provide regular stable release updates for the whole Intrepid is the key here: have you already defined plans for firefox-3.1 maintenance? If so, I'm not against its inclusion.

Given the current state of the Gutsy firefox-3.0 package I am against this
unless we have some firm commitments.

hm... we're rapidly approaching FinalFreeze, so I guess we should either come to a conclusion really soon now, or have already passed the point, and backports would be a more practical approach.

As far as I've read it, the main point of objection is an uncertain duration of support from mozilla team. Alexander, can you guarantee support for the lifecycle of intrepid for the packages?

No, our support promise is like what i proposed. I think thats good enough because users that go for 3.1 in intrepid are 99.9% users that will go for jaunty once that is released.

Remember that such kind of guarantee is not required (read: enforced) for any universe package atm.

Otherwise, we should go through the archive, think a minute if we do support that and if not, remove it. Nobody did that in the past and if we want to do that we shouldnt start just now.

Well, the problem in regards to support here seems to be that only the mozilla team *can* in fact provide fixes due to trademark restrictions, which is not true for other packages. Or are we allowed by mozilla to upload unapproved fixes to stable releases?

Also, I'm curious: Do you estimate it likely that the user base will have backports enabled? If so, I guess using backports for this would make more sense.

I don't think 6 months of support is sufficient. -1 from me.

On Wed, Oct 15, 2008 at 01:26:24PM -0000, StefanPotyra wrote:
> Well, the problem in regards to support here seems to be that only the
> mozilla team *can* in fact provide fixes due to trademark restrictions,
> which is not true for other packages. Or are we allowed by mozilla to
> upload unapproved fixes to stable releases?

This isnt true. The backports for gutsy were done by MOTU contributors
(e.g. jdong). The only reason taht stopped was that nobody uses gutsy
who used that. Hence the promise to provide security support until
jaunty is released.

>
> Also, I'm curious: Do you estimate it likely that the user base will
> have backports enabled? If so, I guess using backports for this would
> make more sense.
>

Well, if you estimate that they have, then you can also guess that
users will upgrade to jaunty on first breath. we can extend the
support promise throughout half of jaunty, so people have some time to
upgrade. But I am almost certain that all that seriously use 3.1 beta
now, will go for jaunty at one point or the other.

 - Alexander

On Wed, Oct 15, 2008 at 01:47:22PM -0000, Scott Kitterman wrote:
> I don't think 6 months of support is sufficient. -1 from me.
>

OK, next cycle we should then go through the archive and drop
everything that doesnt have a firm security support commitment?

Again, binding a feature freeze exception to a security support
promise doesnt make sense as nobody would have removed the package if
we would have uploaded _before_ the feature freeze.

 - Alexander

Agreed. There's nothing I can do to prevent unsupportable packages being
uploaded before FF. That doesn't mean I think it's a good idea.

In Gutsy we have a firefox-3.0 package in the release pocket that is
obsolete, vulnerable, and cannot be removed. I've spoken to jdong about
the one in gutsy-backports and he agreed to update it or have it removed
(unlike -release, -backports can be removed).

While there may be a few exceptions, the general consensus from MOTU is
that we cannot maintain this package due to the way it is licensed, so I
believe motu-release is supporting the team consensus here.

It is possible intrepid-backports can be available at release time. That
may be a better place for this package. It wouldn't have the same support
requirements since it could be removed when no longer needed. The
requirement to only backport from the development release can be waived if
needed.

Scott, thanks. Especially the argument that we can remove packages from -backports is a good one given the timing of this. Also since the archive is closed now, lets look for backports.

FWIW, we should surely work on our MOTU policies to make clear what we want, how we want it and how we can do that in a scalable fashion.

btw, i dont think we should remove the backport from gutsy. remoiving a buggy package while a even buggier one is still in in release doesnt make much sense.

I still intend on updating Firefox 3.0 in gutsy-backports and it'd be great to be able to work with Mozilla Team to make newer Firefox releases available in the backports pocket. I think it's fairly well understood that Backports is maintained on a best-effort basis and that's still frankly a lot better than the ways the general user population will resort to for installing their latest crack.

On Thu, Oct 16, 2008 at 02:41:54PM -0000, John Dong wrote:
> I still intend on updating Firefox 3.0 in gutsy-backports and it'd be
> great to be able to work with Mozilla Team to make newer Firefox
> releases available in the backports pocket. I think it's fairly well
> understood that Backports is maintained on a best-effort basis and
> that's still frankly a lot better than the ways the general user
> population will resort to for installing their latest crack.
>

Fabien and me are currently working on doing a backport and making a
proper branch out of it. Help appreciated. You know where to find us ;).

 - Alexander

On Sun, Oct 19, 2008 at 7:05 PM, Alexander Sack <email address hidden> wrote:

> On Thu, Oct 16, 2008 at 02:41:54PM -0000, John Dong wrote:
> > I still intend on updating Firefox 3.0 in gutsy-backports and it'd be
> > great to be able to work with Mozilla Team to make newer Firefox
> > releases available in the backports pocket. I think it's fairly well
> > understood that Backports is maintained on a best-effort basis and
> > that's still frankly a lot better than the ways the general user
> > population will resort to for installing their latest crack.
> >
>
> Fabien and me are currently working on doing a backport and making a
> proper branch out of it. Help appreciated. You know where to find us ;).
>
Sigh premature-upload seems to sum up my private life and Ubuntu life.
Backports PPA has a 3.0.3 backport that merges the changes from hardy ->
hardy-security debdiff into the original backports.

I saw your gutsy-backport branch and as of last Friday it was a bit out of
date so I decided to do it from familiar ground for me. So far these
packages test well for me.

On Sun, Oct 19, 2008 at 11:21:02PM -0000, John Dong wrote:
> On Sun, Oct 19, 2008 at 7:05 PM, Alexander Sack <email address hidden> wrote:
>
> > On Thu, Oct 16, 2008 at 02:41:54PM -0000, John Dong wrote:
> > > I still intend on updating Firefox 3.0 in gutsy-backports and it'd be
> > > great to be able to work with Mozilla Team to make newer Firefox
> > > releases available in the backports pocket. I think it's fairly well
> > > understood that Backports is maintained on a best-effort basis and
> > > that's still frankly a lot better than the ways the general user
> > > population will resort to for installing their latest crack.
> > >
> >
> > Fabien and me are currently working on doing a backport and making a
> > proper branch out of it. Help appreciated. You know where to find us ;).
> >
> Sigh premature-upload seems to sum up my private life and Ubuntu life.
> Backports PPA has a 3.0.3 backport that merges the changes from hardy ->
> hardy-security debdiff into the original backports.
>
> I saw your gutsy-backport branch and as of last Friday it was a bit out of
> date so I decided to do it from familiar ground for me. So far these
> packages test well for me.
>

Urgh. Thanks, anyway, now i feel a bit scared :). does that work properly?
could you help us to get this in a proper branch. would help us a lot
to fix long term maintenance for that branch.

 - Alexander

Yeah, I'd like to do it properly too -- where is the bzr branch for Firefox as of hardy-security? Somehow I couldn't find one that matches up on the firefox or xulrunner product pages?

On Mon, Oct 20, 2008 at 01:17:36PM -0000, John Dong wrote:
> Yeah, I'd like to do it properly too -- where is the bzr branch for
> Firefox as of hardy-security? Somehow I couldn't find one that matches
> up on the firefox or xulrunner product pages?
>

Please check with fta on irc to sort out what to do now :) ...

 - Alexander

xulrunner-1.9.1 (1.9.1~b2+build1+nobinonly-0ubuntu3) jaunty; urgency=low

  New upstream release: 1.9.1 beta 2 from FIREFOX_3_1b2_BUILD1 (LP: #274187)

  [ Alexander Sack <email address hidden> ]
  * add patch to eliminate long deprecated GTK_CHECK type macros from
    gtkmozembed code; instead we use the current G_TYPE/OBJECT macros
    - add debian/patches/bz461277_att344402_eliminate_deprecated_gtk_type_macros.patch
    - update debian/patches/series
  * we explicitly use -O0 -g as optimize flags for |noopt| builds
    - update debian/rules
  * drop patches superseeded by upstream fix
    - delete debian/patches/ARMEL_Wno_error_in_network_cookie_src.patch
    - update debian/patches/series
  * polish "save password" prompt patch for upstream submission and send
    upstream
    - rename and update debian/patches/bzXXX_attXXX_fix_remember_password_for_embedders_without_branding.patch
      => bz466923_att350251_password_prompt_branding_fallback.patch

  [ Fabien Tassin <email address hidden> ]
  * Resurrect the -dbg package, at least until bug 156575 is fixed
    - update debian/control
  * Add a version to pkg-config files so the -dev package could coexist with
    xulrunner 1.9
    - add debian/patches/install_pkgconfig_files_with_version.patch
    - update debian/patches/series
  * Drop 'Breaks' from xulrunner-1.9.1 and drop the xulrunner-dev meta package
    - update debian/control
  * Drop --enable-webservices and --enable-safe-browsing
    - update debian/rules
  * Build DEB_MOZ_EXTENSIONS=default
    - update debian/rules
  * Update requirement for system sqlite3 to >= 3.6.2
    - update debian/rules
  * Update requirement for system nspr to >= 4.7.3 and for nss to >= 3.12.2
    - update debian/rules
  * Drop support for venkman and dom-inspector, no longer in the tree
    - update debian/rules
    - drop debian/patches/bz428848_att319775_fix_venkman_chrome_access.patch
    - drop debian/patches/rename_venkman_addon.patch
    - drop debian/patches/dom_inspector_support_for_prism.patch
    - update debian/patches/series
  * Fix FTBFS introduced by cairo 1.8.4 which is now built with directfb
    by default.
    - add debian/patches/fix_ftbfs_with_cairo_fb.patch
    - update debian/patches/series
  * Update EM_TRANSLATION_MAX_VERSION to match xulrunner version
    - update debian/rules
  * Add libasound2-dev to Build-Depends for the new HTML5 <video> tag
    - update debian/control
  * Run autoconf in js/src now that SpiderMonkey has its own build system
    - update debian/rules
  * Make the prerm script a .in file as we need to pass some variables
    - rename debian/xulrunner-1.9.1.prerm => debian/xulrunner-1.9.1.prerm.in
    - update debian/rules
  * Drop obsolete /etc/gre.d files generated by this package
    - update debian/xulrunner-1.9.1.preinst
  * Prevent the build system to be exported twice
    - update debian/rules
  * Drop to in-source hunspell when system hunspell is not at least 1.2.*.
    This is needed for hardy.
    - update debian/rules
  * Update patch series file missing bz466923_att350251_password_prompt_branding_fallback.patch
    - update update debian/patches/series
  * Remove patches applied upstream
    - drop debian/p...

firefox-3.1 (3.1~b2+build1+nobinonly-0ubuntu1) jaunty; urgency=low

  New upstream release: 3.1 beta 2 from FIREFOX_3_1b2_BUILD1 (LP: #274187)

  [ Fabien Tassin <email address hidden> ]
  * Change appname and use a dedicated profile so 3.1 could run along with
    3.0 without locking/corrupting the profile. Initial 3.1 profile is
    cloned from 3.0 whenever possible.
    - update debian/firefox.sh.in
    - add debian/patches/firefox-profilename
    - add debian/patches/firefox-fsh
  * Use Shiretoko, codename for 3.1 instead of Granparadiso
    - rename debian/firefox-3.1-granparadiso.desktop => firefox-3.1-shiretoko.desktop
    - update debian/rules
  * Unset FORCE_OFFICIAL_BRANDING to return to minefield branding for
    intermediate snapshots and to Shiretoko branding for milestones
    - update debian/rules
  * Set MALLOC_OPTIONS=O before calling xulrunner during build. This is needed
    to avoid a dead-lock in jemalloc when running under fakeroot
    - update debian/rules
  * Drop system nspr/nss (until the soname work is stable)
    - update debian/rules
  * Update requirement for system sqlite3 to >= 3.6.0
    - update debian/rules
  * Add libasound2-dev to Build-Depends for the new HTML5 <video> tag
    - update debian/control
  * Drop dom-inspector, venkman and legacy firefox-{,trunk,granparadiso}
    packages
    - update debian/control
  * Resurrect the -dbg package, at least until bug 156575 is fixed
    - update debian/control
  * Update diverged patches:
    - update debian/patches/nspr_flags_by_pkg_config_hack.patch
    - update debian/patches/bzXXX_reload_new_plugins.patch
    - update debian/patches/firefox-fsh
    - update debian/patches/firefox-profilename
    - update debian/patches/lp185622_system_path_default_browser.patch
    - update debian/patches/browser_branding.patch
  * Drop patches applied upstream
    - drop debian/patches/lp269656_know_your_rights.patch
      (See https://bugzilla.mozilla.org/show_bug.cgi?id=456439)
    - drop debian/patches/installer_use_stdout_for_missing_files.patch
    - drop debian/patches/bz412610_att335369_realpath_overflow.patch
    - drop debian/patches/bz436133_att322801.patch
    - drop debian/patches/bz421977_att334578.patch
    - update debian/patches/series

  [ Alexander Sack <email address hidden> ]
  * ship $MOZ_APP_DIR/distribution/distribution.ini
    - add debian/distribution.ini
    - update debian/rules

 -- Fabien Tassin <email address hidden> Fri, 28 Nov 2008 16:02:43 +0100