Relanding the new Add-ons Manager on Monday, potential Ts disruption on OSX 10.5.8
Dave Townsend
regression on OSX 10.5.8. We've now verified that this is a recurrence
of the old bug 519893 that my changes are randomly causing to happen.
Since headless is not a common environment for Firefox and others
landings are hitting this too we believe the solution is to install new
dongles on all the Rev3 Leopard boxes and carry on
(https://bugzilla.mozilla.org/show_bug.cgi?id=563836).
This could take a little time however so I'd like to ask if anyone would
object to me relanding the new Add-ons Manager in the meantime. Since
the tree is closed I would expect to do this on Monday morning PDT.
The only real downside to landing it before the talos boxes are all
dongled up is that we'll see higher and noisier Ts numbers on OSX 10.5.8
for a time. It's possible this could mask other Ts regressions, but only
in the event that they only affect that one platform, we still seem to
get good numbers of OSX 10.6 as well as Windows and Linux.
Gary
work with limited functionality. Perhaps there should be more
documentation for the add-on developers to help them update their
software. Maybe a conversion program or at least a program that
identifies incompatibilities in add-ons with the new Manager.
Mike Beltzner
Was this reported when it first landed?
The trunk (mozilla-central) is the place to land things which change API compatibility, and always has been. I agree that if there is not yet documentation on what changes must be made that we should prioritize the creation of that documentation, but I'm curious to know if it's the case that all add-ons fail, or a certain class, etc.
For what it's worth all of the add-ons I had continued to work!
cheers,
mike
Dave Townsend
It was always expected that a number of add-ons would break where they
are using the old APIs. I blogged about this a while ago
(http://www.oxymoronical.com/blog/2010/03/How-were-breaking-some-extensions-in-the-near-future)
and I know at least some authors picked it up and started to work on it.
I don't believe that we should be holding off trunk landings until
developers fix their add-ons though. We never have in the past and
perhaps more importantly we have no real good way of reaching out to
developers to warn them to fix these things. The sooner we land the
sooner developers will hear/see that their add-ons are broken and the
sooner they will look up how to fix them.
Mike Beltzner
> It was always expected that a number of add-ons would break where they are using the old APIs. I blogged about this a while ago (http://www.oxymoronical.com/blog/2010/03/How-were-breaking-some-extensions-in-the-near-future) and I know at least some authors picked it up and started to work on it.
Not the author of Nightly Tester Tools. Sheesh - that guy! ;)
cheers,
mike
geeknik
it back in so we can test it and iron out any problems that come up.
This is the trunk after all and things break. =)
Philip Chee
Admittedly I had to go in and out of safe mode several time before any
of my extensions came back. And when the old EM was put back all my
extensions disappeared again. Deleting compreg/xpti.dat and extensions.*
didn't work. In the end I think touching the components.list in the
installation directory forced SeaMonkey 2.1a1pre to recognize the old EM
Cc contract id and Ci.
P.S. SeaMonkey trunk is currently frozen for a 2.1a1 alpha release,
could you guys please try not to land the new EM until we've shipped?
Yes yes I know very selfish of us.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Well...my cray is in the shop.
* TagZilla 0.066.6
Philip Chee
I managed to fix a problem xSidebar had with the new EM but the old EM
came back before I could test my fix thoroughly. Sigh.
Mike Connor
On 2010-05-07, at 10:20 PM, Philip Chee <phili...@gmail.com> wrote:
> P.S. SeaMonkey trunk is currently frozen for a 2.1a1 alpha release,
> could you guys please try not to land the new EM until we've shipped?
> Yes yes I know very selfish of us.
Why not use a gecko alpha tag as the base for your alphas? Seems like
the best bet for stability.
- Mike
Justin Wood (Callek)
Me, KaiRo and Mossop have been back and forth over the SM Freeze and the
Addons Manager.
As an assistant to the SeaMonkey release driver people, I do not feel
our freezing should block the new manager landing.
--
~Justin Wood (Callek)
sabret00the
I vote to land it.
Robert Kaiser
> Why not use a gecko alpha tag as the base for your alphas? Seems like
> the best bet for stability.
Because our code isn't tested for versions of m-c that don't match c-c
time-wise, and prediction of Firefox/platform schedules in 1.9.3 has
been found impossible so far, so we make up our schedules as they fit us.
Still, as Callek rightly said, we've been discussing this between Mossop
and our team, and whatever we're doing here should not hold off that
landing by any means - being notified (as we have in here) of when it's
happening is helpful though, so we can make sure to cut a relbranch
before that and hopefully be just fine. :)
Robert Kaiser
Dave Townsend
> This could take a little time however so I'd like to ask if anyone would
> object to me relanding the new Add-ons Manager in the meantime. Since
> the tree is closed I would expect to do this on Monday morning PDT.
So the general consensus seems to be that the perf issue isn't one tat
should hold back landing so I intend to do this at the first
opportunity. Unfortunately the tree is closed right now with no obvious
ETA for reopening so I can't say exactly when this will be.