Nightly testers needed for mozilla-central
Benjamin Smedberg
using automatic update since them may be in for a surprise: you are no
longer using Minefield or testing mozilla-central.
Since the branch of 1.9.1, nightly users have been updated to the same major
version, which means they are now tracking the 1.9.1 branch (Shiretoko
nightlies). Right now, we have many more nightly testers on the stable
branch than we do on mozilla-central. But we really want to catch
regressions in mozilla-central before then land on the stable branch. If you
are a nightly tester (or want to become one!), please go download and
install a new Minefield build today!
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
For a pretty picture, see
http://benjamin.smedbergs.us/blog/2008-12-18/nightly-testers-needed-for-mozilla-central/
--BDS
Mike Beltzner
> Users who installed a build of Minefield before 24 November and have
> been
> using automatic update since them may be in for a surprise: you are no
> longer using Minefield or testing mozilla-central.
If you're wondering "zomg! how can I check?", simply take a look at
the title of your application.
Minefield = trunk nightly
Shiretoko = 1.9.1 branch nightly
The "About" dialog will also contain this diagnostic information :)
> nightlies). Right now, we have many more nightly testers on the stable
> branch than we do on mozilla-central. But we really want to catch
By my reading of tea leaves and AUS pings, we've got about an order of
magnitude of difference here, to give a better sense of things.
There's an implication here for developers as well, which is that
while patches destined for 1.9.1 should indeed be baked first on
mozilla-central to spot test and performance regressions, we're not
getting the web-compatibility coverage from the mozilla-central
nightlies that we are from the 1.9.1-branch nightlies. So if you have
a patch that's for a blocker, or a patch with approval1.9.1+, and
you've yet to land it on the 1.9.1-branch ... bombs away, vite-vite!
cheers,
mike
John J. Barton
...
> nightlies). Right now, we have many more nightly testers on the stable
> branch than we do on mozilla-central. But we really want to catch
> regressions in mozilla-central before then land on the stable branch. If you
> are a nightly tester (or want to become one!), please go download and
> install a new Minefield build today!
My immediate reaction to this was, "wait, don't leave me like this". I
think the real problem is the branch was taken too soon. I find FF3.1b2
barely usable and I'm wondering if we should delay Firebug work on FF3.1
until b3.
jjb
Benjamin Smedberg
> My immediate reaction to this was, "wait, don't leave me like this". I
> think the real problem is the branch was taken too soon. I find FF3.1b2
> barely usable and I'm wondering if we should delay Firebug work on FF3.1
> until b3.
I don't know... it depends on what problems you're encountering. I suspect
you mean "barely usable for developing firebug" and not barely usable in
general, right? I haven't encountered any significant problems with the
branch builds.
I suspect that if your problems are primarily related to JS debugging, they
might be fixed by preffing off JIT for the time being (and making sure bugs
are filed on bad JIT/debugger interactions).
--BDS
Damon Sicore
Can you please be specific? Ideally, point us to some bug numbers?
>
>
> jjb
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Mike Beltzner
keeping Firebug from working with 3.1 those should be nominated as P1
blockers. Our goal is to have full add-on compatibility by Beta 3, so that
web developers move to the new product by that milestone.
cheers,
mike
Dan Mosedale
> while patches destined for 1.9.1 should indeed be baked first on
> mozilla-central to spot test and performance regressions,
So the above sounds like there's no policy change about landing order.
> we're not
> getting the web-compatibility coverage from the mozilla-central
> nightlies that we are from the 1.9.1-branch nightlies. So if you have a
> patch that's for a blocker, or a patch with approval1.9.1+, and you've
> yet to land it on the 1.9.1-branch ... bombs away, vite-vite!
But this sounds like there has been a policy change.
Can you clarify?
Thanks,
Dan
Benjamin Smedberg
There has been no policy change. You have to land on mozilla-central first.
What beltzner means is that you shouldn't wait a long time after landing on
mozilla-central to land on 1.9.1.
--BDS
Mike Beltzner
There is no policy change.
There is also no need to let patches languish, unlanded on the 1.9.1 branch
after enough bake time has gone by to spot test and performance regressions.
Leaving them baking to spot web compatibility regressions is inappropriate,
as we don't have the test breadth there.
What I'm saying is that we've got a bunch of patches with permission (either
as blocker fixes or with approval1.9.1+) that haven't landed on branch, and
we should get them landed so we can ensure we're not seeing unexpected
stability and web-compatibility problems.
cheers,
mike
----- Original Message -----
From: dev-planning-bounces+beltzner=mozil...@lists.mozilla.org
<dev-planning-bounces+beltzner=mozil...@lists.mozilla.org>
To: dev-pl...@lists.mozilla.org <dev-pl...@lists.mozilla.org>
Sent: Thu Dec 18 12:49:55 2008
Subject: Re: Nightly testers needed for mozilla-central
On 12/18/08 7:52 AM, Mike Beltzner wrote:
> while patches destined for 1.9.1 should indeed be baked first on
> mozilla-central to spot test and performance regressions,
So the above sounds like there's no policy change about landing order.
> we're not
> getting the web-compatibility coverage from the mozilla-central
> nightlies that we are from the 1.9.1-branch nightlies. So if you have a
> patch that's for a blocker, or a patch with approval1.9.1+, and you've
> yet to land it on the 1.9.1-branch ... bombs away, vite-vite!
But this sounds like there has been a policy change.
Can you clarify?
Thanks,
Dan
John J Barton
> On 12/18/08 12:54 PM, John J. Barton wrote:
>
>> My immediate reaction to this was, "wait, don't leave me like this". I
>> think the real problem is the branch was taken too soon. I find FF3.1b2
>> barely usable and I'm wondering if we should delay Firebug work on FF3.1
>> until b3.
>
> I don't know... it depends on what problems you're encountering. I suspect
> you mean "barely usable for developing firebug" and not barely usable in
> general, right? I haven't encountered any significant problems with the
> branch builds.
Yes, for developing firebug. In fact my small experience with using
Firebug on FF3.1 is that it works.
>
> I suspect that if your problems are primarily related to JS debugging, they
> might be fixed by preffing off JIT for the time being (and making sure bugs
> are filed on bad JIT/debugger interactions).
No. I do hear this a lot, and I suppose its a natural reaction, but so
far I have seen no issues regarding the JIT. My issues seem to derive
from -chrome <chromeurl> usage
>
> --BDS
>
Benjamin Smedberg
>> I suspect that if your problems are primarily related to JS debugging,
>> they
>> might be fixed by preffing off JIT for the time being (and making sure
>> bugs
>> are filed on bad JIT/debugger interactions).
>
> No. I do hear this a lot, and I suppose its a natural reaction, but so
> far I have seen no issues regarding the JIT. My issues seem to derive
> from -chrome <chromeurl> usage
Bugs filed? I don't know of any changes that happened to the behavior of the
-chrome commandline handler, and your description is pretty vague ;-)
--BDS
John J Barton
> More specifically, and I'm sure we've said this before: if there are things
> keeping Firebug from working with 3.1 those should be nominated as P1
> blockers. Our goal is to have full add-on compatibility by Beta 3, so that
> web developers move to the new product by that milestone.
>
> cheers,
> mike
>
Having a goal of FF3.1b3 is fine, that is what I was saying. The
problems I have with b2 are being addressed. But the timing is not
great, b2 being not good enough and b3 being quite in the future.
For FF3.2 I think we should schedule an explicit war party day to insure
that dev tool bugs are addressed in advance of extension developers work.
jjb
John J Barton
> On 12/18/08 4:21 PM, John J Barton wrote:
>> far I have seen no issues regarding the JIT. My issues seem to derive
>> from -chrome <chromeurl> usage
>
> Bugs filed? I don't know of any changes that happened to the behavior of the
> -chrome commandline handler, and your description is pretty vague ;-)
>
> --BDS
Well 465993 makes progress very painful.
Something to think about: a general reaction to "its broken" is "which
bug numbers"? (also exactly my reaction to firebug users). But this is
very unsatisfactory, because the cost of creating bug reports is so
huge. I'd guess it takes me at least two days to create a bug report.
That's a very big investment when the expected outcome (that is the
outcome reporters expect) is "duplicate" at best.
So I should have pushed on 465993 two months ago since it prevent work
that might have made FF3.1b2 viable for firebug work. But when I try
something and it has multiple serious issue each which may take two days
of dubious work, I find that other efforts attract my attention.
jjb
Damon Sicore
Also, do you have a test suite that we could use to determine when we
break you? Presumably you do. Would be great if we could integrate
those tests.
John J Barton
...
>
> Also, do you have a test suite that we could use to determine when we
> break you? Presumably you do. Would be great if we could integrate
> those tests.
>
No, but we are making good progress. For firebug we have a testing api
and tests for some features of the console and net panels. We don't yet
have a way to drive these from a build. We are also looking into ways
simplify test creation since we have a huge feature space to test. We
expect to do test-verified releases "soon", probably part way through
1.4b. At that point we should be able to create an automatic sanity
check for you.
For chromebug the issue is harder/different. I don't know how to make a
test that is "chromebug comes up and makes sense", which is all I need
beyond firebug unit tests.
jjb
Boris Zbarsky
> I'd guess it takes me at least two days to create a bug report.
Er... why? Is the problem the actual bugzilla interaction? Is it
collecting all the information you think should be in the bug report?
Something else?
-Boris
John J Barton
Some is triage: yours or mine. But then I have to create a test
extension, new profile, refine until it works, then bugzilla and
followups. I have some disadvantages: firebug/chromebug is large, it has
had no test suite of its own and it touches every part of firefox. I've
gotten better; I don't know what could be done to make it significantly
faster.
jjb
Robert Kaiser
> I have some disadvantages: firebug/chromebug is large, it has
> had no test suite of its own and it touches every part of firefox.
I don't want to sound like I'd dislike Firebug here, but to me it sound
like all those are actual bugs in Firebug/Chromebug :p
Robert Kaiser
John J Barton
Well I certainly agree about the test part, which is why its our top
priority (maybe part of the 3.1 problem ;-). But the other two are just
going to be true to have a comprehensive debugger.
Boris Zbarsky
> Well 465993 makes progress very painful.
In the meantime, making sure that you do the open off a timeout that
runs after the window has shown should work. But yeah, we need to fix that.
-Boris
John J Barton
Ok Thanks. I already had the open() in a setTimeout, with 0 time, but
when I gave it 250ms, the window comes up. Well it come up behind every
other window, rather than on top like before.
jjb
biju
> Users who installed a build of Minefield before 24 November and have been
> using automatic update since them may be in for a surprise: you are no
> longer using Minefield or testing mozilla-central.
( Yeah I know, when I saw Shiretoko on the title bar.
So I download Minefield/3.2a1pre )
But question is why you (mozilla.org) are switching us from nightly to
beta.
When we manually downloaded nightly, we meant to be nightly testers.
So please dont automatically switch us from nightly builds!!!
And same for beta versions too.
Even though I use nightly builds
I give beta version for others in family.
Gavin Sharp
> But question is why you (mozilla.org) are switching us from nightly to
> beta.
> When we manually downloaded nightly, we meant to be nightly testers.
>
> So please dont automatically switch us from nightly builds!!!
>
> And same for beta versions too.
> Even though I use nightly builds
> I give beta version for others in family.
Just to be clear, the switch was not from "nightly" to "beta" in
update channel terms. The switch was from nightly builds from
mozilla-central to nightly builds from the 1.9.1 release branch. You
still get a new build daily either way, and 1.9.1 branch nightlies
aren't "beta" until we actually reach that milestone.
Gavin
Tony Mechelynck
Yes, and IIUC the problem is compounded by the fact that ATM,
Thunderbird and SeaMonkey "trunk" nightlies are built based on Gecko
1.9.1 (like Shiretoko), not 1.9.2 (like Minefield).
Best regards,
Tony.
--
Loan-department manager: "There isn't any fine print. At these
interest rates, we don't need it."
biju
http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/6df4062290424479
--- On Sun, Dec 21, 2008 at 4:12 AM, biju wrote:
> But question is why you (mozilla.org) are switching us from nightly
> to beta.
> When we manually downloaded nightly, we meant to be nightly testers.
>
> So please dont automatically switch us from nightly builds!!!
>
> And same for beta versions too.
> Even though I use nightly builds
> I give beta version for others in family.
Gavin Sharp
> Why is this not appearing at
> http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/6df4062290424479
Followup-to was set to mozilla.dev.planning:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/6df4062290424479
Gavin
Dan Mosedale
>>
>> For a pretty picture, see
>> http://benjamin.smedbergs.us/blog/2008-12-18/nightly-testers-needed-for-mozilla-central/
>>
>>
>> --BDS
>
> Yes, and IIUC the problem is compounded by the fact that ATM,
> Thunderbird and SeaMonkey "trunk" nightlies are built based on Gecko
> 1.9.1 (like Shiretoko), not 1.9.2 (like Minefield).
For Thunderbird, that's not exactly right; the current nightlies have
essentially morphed into being "branch" nightlies, and we're still
working on getting new "trunk" nightlies set up.
Dan