Cherrypicking changesets for FF7 aurora

25 views
Skip to first unread message

Christopher D. Leary

unread,
Jul 5, 2011, 9:13:00 PM7/5/11
to dev-tech-js-en...@lists.mozilla.org
I just merged the following bugs to mozilla-central. Unfortunately,
the merge from m-c to aurora happened this morning (*before* my merge)
so if any of these need to make it to FF7 we need to cherry pick them
via the aurora approval flag. Please look through this list of bugs
and see if one of yours is in there that should be requesting aurora
approval.

- Chris

P.S. You'll notice the target milestone has been set to mozilla8 --
the merge bot will be able to set milestones from now on to let you
know what FF version your changes were merged into.

Bug 590973 - Reflect.parse(): expose to chrome as a toolkit component
(r=gal)')],
Bug 627859: Use the standard placeholder-making function when
re-scoping variable references in generator 'yield' expressions.
r=brendan")],
Bug 630897 - Reflect.parse(): catch clauses should always be an array
(r=jorendorff)')],
Bug 634156 - Come up with a way of creating an API in content that
exposes real content objects without using a sandbox.
r/sr=jst/mossop/gal'),
Fix bustage from bug 634156.')],
Bug 635617 - 64-bit crash [@ MakeDay] r=jwalden')],
bug 637136 - const-ify JS_ON_TRACE (r=luke)')],
Bug 645922 - Remove nsIJSON.encode/decode, because their functionality
is subsumed by JSON.parse and JSON.stringify, and their idiosyncrasies
are hindering code improvements. Also remove js_TryJSON and
JS_TryJSON, which are no longer used after these changes and have no
clear use cases. r=brendan, r=jst')],
Bug 646574 - dis() is broken when the function being disassembled has
upvars. r=mrbkap')],
Backout bug 653248 due to bug 667011', is_backout=True)],
Bug 657298 - Various bugs in setting the length of an array. r=dmandelin')],
Bug 660371: report regexp syntax errors as compiler errors when
appropriate, r=cdleary')],
Bug 660797 - Don't accidentally lift the prototype property onto the
element itself. r=jorendorff")],
Bug 664689 - Deal with wrappers-around-wrappers here. r=gal')],
Bug 665355 - Fix __proto__ recursion. r=mrbkap'),
Bug 665355 - Make delegate object and ArrayBuffer share same
prototype. r=mrbkap')],
Bug 665914 - ArrayBuffer.prototype['byteLength'] crashes. r=mrbkap")],
Bug 666448: Remove 2nd argument to escape() for ECMA/Test262
compliance (r=jwalden)')],
Bug 666480: Remove set-but-not-used variable 'priorIns' from LIR.cpp.
r=wmaddox")],
Bug 666488 - [TM] Re-enable YARR on sparc. r=dvander.')],
Bug 666599 - Fix ArrayBuffer::obj_lookupProperty. r=mrbkap')],
Bug 667056 - Fix when function callbacks are invoked (r=luke)')],
Bug 667076 - Add a CHECK_EQUAL for testing whether non-jsval types are
equal and report expected and observed values on failure (r=luke)'),
Bug 667076 - follow up for bustage on Win64. r=luke')],
Bug 667126: Allow WeakMaps where the criterion for retaining an entry
does not imply that the entry's key has been marked. r=jorendorff")],
Bug 667131 - crash: 'yield' unnoticed due to calling
maybeNoteGenerator() too late (r=cdleary)")],
Bug 667504: Allow atom declaration updates in linked list form. (r=luke)')],
Bug 667527 - Remove the array-length limitation from the method used
in certain cases to append values to newborn arrays, and name it more
generally than previously. r=dmandelin')],
Bug 667538 - Crash accessing Function.caller or Function.arguments
when no script is running. r=evilpie')],
Bug 667630 - Don't treat the payload of a jsval as a pointer and make
sure we unroot the value. r=luke")],
Bug 667646 - fun.caller should be null, not undefined, when fun is
being called by global code. r=evilpie')],
Bug 667824 - Make tracer match changes to JSOP_CALL (r=waldo)')],
Bug 668261 - Change EvalInContext to not clobber callee early; don't
propagate rval on js::Execute failure so that rval-clobbering callers
don't trigger assert (r=waldo)")]}

Benjamin Smedberg

unread,
Jul 6, 2011, 12:40:51 AM7/6/11
to Christopher D. Leary, dev-tech-js-en...@lists.mozilla.org
On 7/5/11 9:13 PM, Christopher D. Leary wrote:
> I just merged the following bugs to mozilla-central. Unfortunately,
> the merge from m-c to aurora happened this morning (*before* my merge)
> so if any of these need to make it to FF7 we need to cherry pick them
> via the aurora approval flag. Please look through this list of bugs
> and see if one of yours is in there that should be requesting aurora
> approval.
In case it's not clear: please do *not* request approval for new
features. Aurora exists as a stabilization point for features which were
done at the branch time, to fix or back out regressions, and to fix
critical security/stability issues, and we do not plan on taking feature
or generic cleanup work.

--BDS

Brendan Eich

unread,
Jul 6, 2011, 1:07:21 AM7/6/11
to Benjamin Smedberg, Dave Herman, Christopher D. Leary, dev-tech-js-en...@lists.mozilla.org
cdleary's merge missed the m-c to aurora merge by less than a day, so we should consider each changeset to see if it was intended for Firefox 7.

Skipping cleanup fixes such as:

Bug 627859: Use the standard placeholder-making function when re-scoping variable references in generator 'yield' expressions. r=brendan

and:

Bug 666480: Remove set-but-not-used variable 'priorIns' from LIR.cpp. r=wmaddox

is possibly going to make merge conflicts. It's silly to reject this change on bureaucratic grounds.

What about this one?

Backout bug 653248 due to bug 667011', is_backout=True)

Seems like it is a backout of something already merged from into m-c from tm, therefore already in Aurora.

At least these should be taken:

Bug 590973 - Reflect.parse(): expose to chrome as a toolkit component (r=gal)

Bug 634156 - Come up with a way of creating an API in content that exposes real content objects without using a sandbox. r/sr=jst/mossop/gal

Bug 630897 - Reflect.parse(): catch clauses should always be an array (r=jorendorff)

Bug 634156 - Come up with a way of creating an API in content that exposes real content objects without using a sandbox. r/sr=jst/mossop/gal

and followup cset: Fix bustage from bug 634156. See https://bugzilla.mozilla.org/show_bug.cgi?id=634156#c22 where Nick argues for Aurora approval.

Bug 657298 - Various bugs in setting the length of an array. r=dmandelin

Bug 660371: report regexp syntax errors as compiler errors when appropriate, r=cdleary

Bug 660797 - Don't accidentally lift the prototype property onto the element itself. r=jorendorff

Bug 664689 - Deal with wrappers-around-wrappers here. r=gal

Bug 665355 - Fix __proto__ recursion. r=mrbkap

Bug 665355 - Make delegate object and ArrayBuffer share same prototype. r=mrbkap

Bug 665914 - ArrayBuffer.prototype['byteLength'] crashes. r=mrbkap

Bug 666448: Remove 2nd argument to escape() for ECMA/Test262 compliance (r=jwalden)

Bug 666488 - [TM] Re-enable YARR on sparc. r=dvander.

Bug 666599 - Fix ArrayBuffer::obj_lookupProperty. r=mrbkap

Bug 667056 - Fix when function callbacks are invoked (r=luke)

Bug 667076 - Add a CHECK_EQUAL for testing whether non-jsval types are equal and report expected and observed values on failure (r=luke)

Bug 667076 - follow up for bustage on Win64. r=luke

Bug 667126: Allow WeakMaps where the criterion for retaining an entry does not imply that the entry's key has been marked. r=jorendorff

Bug 667131 - crash: 'yield' unnoticed due to calling maybeNoteGenerator() too late (r=cdleary)

Bug 667504: Allow atom declaration updates in linked list form. (r=luke)

Bug 667527 - Remove the array-length limitation from the method used in certain cases to append values to newborn arrays, and name it more generally than previously. r=dmandelin

Bug 667538 - Crash accessing Function.caller or Function.arguments when no script is running. r=evilpie

Bug 667630 - Don't treat the payload of a jsval as a pointer and make sure we unroot the value. r=luke"

Bug 667646 - fun.caller should be null, not undefined, when fun is being called by global code. r=evilpie

Bug 667824 - Make tracer match changes to JSOP_CALL (r=waldo)

Bug 668261 - Change EvalInContext to not clobber callee early; don't propagate rval on js::Execute failure so that rval-clobbering callers don't trigger assert (r=waldo)

Now, I've just gone through all of these, and wasted more time than it was worth. Every single one of these changes should be taken. There may be more fixes needed for Aurora, just based on what's being fixed here. But we don't get to skip these as "generic cleanup" fixes, and they are not adding new features (Chrome access to Reflect.parse was always targeted at FF7).

Missing a merge by less than a day is not a reason to ship crap.

/be

> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Boris Zbarsky

unread,
Jul 6, 2011, 1:32:12 AM7/6/11
to
On 7/6/11 1:07 AM, Brendan Eich wrote:
> Missing a merge by less than a day is not a reason to ship crap.

Missing a feature for 6 more weeks is not "shipping crap".

It doesn't matter where a feature is _targeted_ for. What makes a
feature new is whether it's adding new code and regression possibilities
and attack surface or not, compared to the pre-landing state, not
whether it's something that someone thought up yesterday.

We have 6 weeks on aurora to stabilize things before pushing out to
beta. If we start eating into that time by landing
potentially-destabilizing things just because they missed the merge and
we really really want them, we will lose. If we start mass-landing
stuff on aurora we will _definitely_ lose at the next aurora merge when
we have to examine every single one of those changesets to see whether
they need to be transplanted. This is not "bureaucratic grounds" for
refusing patches; it's just risk management.

Yes, it sucks that the merge was missed. It really does. I appreciate
that. We should avoid that in the future, imho. How do we best do that?

But no, we should not be taking things on aurora unless they improve
stability, fix security issues, fix regressions from Fx5/Fx6, or fix
compat or regression issues that we only discovered after Fx5 shipped.
And the bar for these last may need to be high. If we shipped a release
with some issue or without some feature, then the presumption is that
the lack is not a stop-ship. Maybe for a particular bug that
presumption is wrong; if so, the case needs to be clearly made in the
bug. Again, this is not bureaucracy for the sake of bureaucracy; it's a
necessary consequence of the tight turn-around times on the releases, as
far as I can tell.

Now maybe you think this whole train model fast-release setup is silly
and we should stop doing it. That's fine, if you want to think that.
But then just say so instead of trying to subvert it.

But if you do buy into the train model, then a missed merge means you
ship the feature/fix 6 weeks later. That's not the end of the world.
It's way better than what we had with Fx4, for sure.

-Boris

P.S. There _are_ fixes in this list that I think we should consider
landing on aurora. I didn't read the full list, but at least bug 667630
fits the "improve stability, it's safe" bill that would at least make me
ask for approval on it. There seem to be other crash fixes in the list too.

Brendan Eich

unread,
Jul 6, 2011, 1:51:00 AM7/6/11
to Boris Zbarsky, dev-tech-js-en...@lists.mozilla.org
On Jul 5, 2011, at 10:32 PM, Boris Zbarsky wrote:

> On 7/6/11 1:07 AM, Brendan Eich wrote:
>> Missing a merge by less than a day is not a reason to ship crap.
>
> Missing a feature for 6 more weeks is not "shipping crap".

Let's focus on reality and particulars. Many of the bugs I went through, and that missing back-out, look serious.


> It doesn't matter where a feature is _targeted_ for. What makes a feature new is whether it's adding new code and regression possibilities and attack surface or not, compared to the pre-landing state, not whether it's something that someone thought up yesterday.

You can stop right here. Arguing like a bureaucrat is not going to make trains of non-crap run on time. It'll just make messes later when the bugs are noticed and someone has to cherry-pick missing fixes through merge conflicts.


> P.S. There _are_ fixes in this list that I think we should consider landing on aurora. I didn't read the full list, but at least bug 667630 fits the "improve stability, it's safe" bill that would at least make me ask for approval on it. There seem to be other crash fixes in the list too.

Well thanks for a post-script that actually gives a hoot about quality, instead of lecturing me on a stupid model that no one should sign up for!

Train model does not mean brain-off bug-chopping. We have to look at every bug, at least to see if it can wait six weeks.

/be

Andreas Gal

unread,
Jul 6, 2011, 2:21:09 AM7/6/11
to Brendan Eich, Benjamin Smedberg, Christopher D. Leary, Dave Herman, dev-tech-js-en...@lists.mozilla.org

Why did the TM merge miss the train? Was the branch-off time announced and we just forgot to merge into m-c in time?

Andreas

> Missing a merge by less than a day is not a reason to ship crap.
>

Christopher D. Leary

unread,
Jul 6, 2011, 2:58:47 AM7/6/11
to Andreas Gal, Benjamin Smedberg, Brendan Eich, Dave Herman, dev-tech-js-en...@lists.mozilla.org
I was on vacation from Thursday through Monday. I didn't realize the
Aurora merge was on 7/5 and I wasn't aware that I had to plan for it,
either. I just did the merge when I always do; namely, the first day
after the weekend.

If people expect me to drive JS issues into trunk, we should get that
sorted out so I know to act on that responsibility. I was under the
impression that everybody was accountable for ensuring their own
issues got into trunk when they had to. Historically, TM committers
have had no issues clarifying with me when the merge was going to
occur.

- Leary

Nicholas Nethercote

unread,
Jul 6, 2011, 3:05:21 AM7/6/11
to Christopher D. Leary, Andreas Gal, Benjamin Smedberg, Brendan Eich, Dave Herman, dev-tech-js-en...@lists.mozilla.org
On Wed, Jul 6, 2011 at 4:58 PM, Christopher D. Leary
<cdl...@mozilla.com> wrote:
> I was on vacation from Thursday through Monday. I didn't realize the
> Aurora merge was on 7/5 and I wasn't aware that I had to plan for it,
> either. I just did the merge when I always do; namely, the first day
> after the weekend.
>
> If people expect me to drive JS issues into trunk, we should get that
> sorted out so I know to act on that responsibility. I was under the
> impression that everybody was accountable for ensuring their own
> issues got into trunk when they had to. Historically, TM committers
> have had no issues clarifying with me when the merge was going to
> occur.

Bug 634156, which I'm interested in, landed in TM on Sunday, June 27.
When was the last TM-to-mc merge prior to today's?

Nick

Christopher D. Leary

unread,
Jul 6, 2011, 3:15:45 AM7/6/11
to Nicholas Nethercote, Andreas Gal, Benjamin Smedberg, Brendan Eich, Dave Herman, dev-tech-js-en...@lists.mozilla.org
$ hg log | grep -B4 -i 'merge.*tracemonkey' | less
[snip]
parent: 71636:cba007ad1747
parent: 72104:a7684eca2bb7
user: Chris Leary <cdl...@mozilla.com>
date: Tue Jul 05 17:30:35 2011 -0700
summary: Merge mozilla-central and tracemonkey.
--
parent: 71161:6933048a247c
parent: 71597:e338daa71bc2
user: Chris Leary <cdl...@mozilla.com>
date: Mon Jun 27 11:07:22 2011 -0700
summary: Merge mozilla-central and tracemonkey.
--
parent: 70790:41d5782eabf2
parent: 71125:d578ca1a42e7
user: Chris Leary <cdl...@mozilla.com>
date: Mon Jun 20 16:49:20 2011 -0700
summary: Merge mozilla central and tracemonkey.
--
parent: 70727:479e2681c25f
parent: 70419:49cfb12c2225
user: Chris Leary <cdl...@mozilla.com>
date: Mon Jun 13 10:00:23 2011 -0700
summary: Merge mozilla-central and tracemonkey.
--
parent: 70390:01459cfa4b93
parent: 70421:b69d30cc0b24
user: Chris Leary <cdl...@mozilla.com>
date: Mon Jun 06 13:17:33 2011 -0700
summary: Merge tracemonkey to mozilla-central.
--
parent: 69771:7e6f3b179644
parent: 70388:0c6e91c6f691
user: Chris Leary <cdl...@mozilla.com>
date: Mon Jun 06 09:41:22 2011 -0700
summary: Merge mozilla-central to tracemonkey.
--

Jeff Walden

unread,
Jul 6, 2011, 3:57:24 AM7/6/11
to Christopher D. Leary, Andreas Gal, Benjamin Smedberg, Brendan Eich, Dave Herman, dev-tech-js-en...@lists.mozilla.org
On 07/05/2011 11:58 PM, Christopher D. Leary wrote:
> If people expect me to drive JS issues into trunk

I am going to be cdleary's best friend now and suggest that we try to make this process less gated on one particular person. If he were suddenly not here next Monday, or some particular day we wanted a merge to happen, who would pick up the slack? How would it happen? What tools would we use to do it? I am going to guess the script to use is bz_merge.py[0]. But that's a guess based on educated guessing about where he develops the merge scripts. And if I had to use it, I'd have to reverse-engineer exactly how to do it. Ideally we all should have a fair inkling of how to do this.

I am not suggesting we continually rotate the duty. It is indeed more efficient for one person to get really good at it, then to do it. But it should be possible for multiple different people, more than two and possibly even more, to do it. And I don't think that's really, meaningfully the case right now.

Jeff

0. http://hg.mozilla.org/users/cleary_mozilla.com/spidermonkey_helpers/file/default/bz_merge.py

Boris Zbarsky

unread,
Jul 6, 2011, 8:26:21 AM7/6/11
to
On 7/6/11 1:51 AM, Brendan Eich wrote:
> We have to look at every bug, at least to see if it can wait six weeks.

Of course. That's the whole point.

Some of the bugs you listed can totally wait six weeks in my opinion.
e.g. bug 660797 we've been shipping for a while, and it's a problem, but
not a stop-ship issue. But that's something for the drivers to make a
call on.

People need to nominate the ones they think can't wait six weeks, with
an explanation of _why_ they can't.

-Boris

Luke Wagner

unread,
Jul 6, 2011, 11:23:29 AM7/6/11
to dev-tech-js-en...@lists.mozilla.org
As a data point, I am watching what is where when I land patches. If
something is going to fix Bad Things (i.e., make us not ship crap), I
try to send it straight to where the Bad Things. Thus, if TM misses
some Aurora merge, its no big deal, by construction. (I'm not saying
I'm perfect at it either, but that's the model I've been operating under.)

Andrew McCreight

unread,
Jul 6, 2011, 12:20:29 PM7/6/11
to Brendan Eich, dev-tech-js-en...@lists.mozilla.org
----- Original Message -----
[snip]

> What about this one?
>
> Backout bug 653248 due to bug 667011', is_backout=True)
>
> Seems like it is a backout of something already merged from into m-c
> from tm, therefore already in Aurora.
[snip]

This one isn't a problem. I landed this backout on trunk first due to its security nature, and just landed it later on TM to avoid merge conflicts because people were working on WeakMaps there.

Andrew

Brendan Eich

unread,
Jul 6, 2011, 12:24:45 PM7/6/11
to Nick Nethercote, dev-tech-js-en...@lists.mozilla.org
Begin forwarded message:

> From: bugzill...@mozilla.org
> Date: July 3, 2011 11:54:01 PM PDT
> To: bre...@mozilla.org
> Subject: [Bug 666058] Don't share chunks for system compartments
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=666058
>
> --- Comment #39 from Nicholas Nethercote [:njn] <nneth...@mozilla.com> 2011-07-03 23:54:01 PDT ---
> (In reply to comment #38)
>>
>> Gregor, if you don't have time, I can land this tomorrow (with the 0/1
>> constants replaced with named constants as mentioned in comment 30). Let me
>> know! Thanks.
>
> And if you do want to land, it's probably best to do so on mozilla-inbound
> (which is merged at least once per day), so you're not relying on the timing of
> a TM-to-mc merge.

This seems like the missing essential ingredient. Not everyone knows about mozilla-inbound or how to use it. Is there a doc link to cite?

(Well done to all involved in this bug, btw.)

/be

Boris Zbarsky

unread,
Jul 6, 2011, 12:29:33 PM7/6/11
to
On 7/6/11 12:24 PM, Brendan Eich wrote:
> This seems like the missing essential ingredient. Not everyone knows about mozilla-inbound or how to use it. Is there a doc link to cite?

https://wiki.mozilla.org/Inbound_Sheriff_Duty (the page name is sorta
misleading; the page includes all information needed to use it).

-Boris

Dave Mandelin

unread,
Jul 6, 2011, 2:42:43 PM7/6/11
to dev-tech-js-en...@lists.mozilla.org
On 7/5/11 10:51 PM, Brendan Eich wrote:
> On Jul 5, 2011, at 10:32 PM, Boris Zbarsky wrote:
>
>> On 7/6/11 1:07 AM, Brendan Eich wrote:
>>> Missing a merge by less than a day is not a reason to ship crap.
>> Missing a feature for 6 more weeks is not "shipping crap".
> Let's focus on reality and particulars. Many of the bugs I went through, and that missing back-out, look serious.
On a quick glance and spot-check, I didn't see anything that I would
classify as stop-ship.

>> It doesn't matter where a feature is _targeted_ for. What makes a feature new is whether it's adding new code and regression possibilities and attack surface or not, compared to the pre-landing state, not whether it's something that someone thought up yesterday.
> You can stop right here. Arguing like a bureaucrat is not going to make trains of non-crap run on time. It'll just make messes later when the bugs are noticed and someone has to cherry-pick missing fixes through merge conflicts.
My take:

- We did not do the TM->mc merge on the desired day to coordinate with
mc->aurora, due to coordination error [1].

- I claim that the best response is to take reasonable action to restore
the originally desired outcome. This doesn't mean strictly following the
standard tree rules, which by necessity were formulated without knowing
that situations like this one could occur. This also doesn't mean doing
whatever we want. It means coming up with an answer that is consistent
with the intent of the tree rules, and helps us out in the current
situation.

- My specific recommendation is to take a green changeset from TM of
Friday, July 1, and merge that directly to Aurora. This brings to Aurora
just those changesets that would have made it to Aurora had we done the
merge at the desired time.

- We also of course need to do something to try prevent this from
happening in the future, but we can work on that offline.

Dave

[1] This was due to a combination of factors, including the cutoff being
the day after a holiday, having an intention to delay the merge to allow
a TI landing (although we didn't actually do that), and not
communicating clearly enough the day of the mc->aurora merge and the
desired TM merge ahead of that.

Boris Zbarsky

unread,
Jul 6, 2011, 3:14:29 PM7/6/11
to
On 7/6/11 2:42 PM, Dave Mandelin wrote:
> - I claim that the best response is to take reasonable action to restore
> the originally desired outcome.

The originally desired outcome, from a non-JS-centric viewpoint, is that
QA starts testing the aurora builds yesterday, on the assumption that
there will be no more potentially-destabilizing changes, with an eye
toward releasing them to aurora users in a few days.

There's no way you can "restore" that outcome by merging things to
aurora en masse. If you do that, QA will need to start over.

> This doesn't mean strictly following the standard tree rules, which by necessity were formulated without knowing
> that situations like this one could occur.

On the contrary, they were formulated with the assumption that merges
_would_ be missed for whatever reason. This is why we have a short
release cycle (for most things that miss a merge) and an approval
process (for things that really really do need to get shipped ASAP).

> It means coming up with an answer that is consistent
> with the intent of the tree rules, and helps us out in the current
> situation.

Yes, but with "us" perhaps more broadly defined than "the JS team".....

In any case, this is probably a conversation you want to have directly
with the aurora drivers, of whom I bet close to none are reading this
newsgroup.

-Boris

Jason Orendorff

unread,
Jul 6, 2011, 3:33:54 PM7/6/11
to Boris Zbarsky, dev-tech-js-en...@lists.mozilla.org
On 7/6/11 2:14 PM, Boris Zbarsky wrote:
> In any case, this is probably a conversation you want to have directly
> with the aurora drivers, of whom I bet close to none are reading this
> newsgroup.

Totally.

Whoever brings this to the Aurora drivers might want to mention that:

- the patches in question were not developed or tested in a rush at the
last minute; they landed routinely when they were ready, and have baked
in TM without incident, some of them for a week or more

- they do not include anything that wasn't intended for FF7

- they've been tested together more than separately

- one of them at least is a crash fix; there is of course some risk in
not taking patches that people expected to go in

So there really is a reason to believe this pile of changes is safer
than the average "oh I missed the train make a special exception for me"
patch. It is certainly safer to take them all than to take none, and
likely safer to take them all than to transplant individual patches.

-j

Paul Biggar

unread,
Jul 6, 2011, 3:45:33 PM7/6/11
to Jason Orendorff, Boris Zbarsky, dev-tech-js-en...@lists.mozilla.org
On Wed, Jul 6, 2011 at 12:33, Jason Orendorff <joren...@mozilla.com> wrote:
> On 7/6/11 2:14 PM, Boris Zbarsky wrote:
>>
>> In any case, this is probably a conversation you want to have directly
>> with the aurora drivers, of whom I bet close to none are reading this
>> newsgroup.
>
> Totally.
>
> Whoever brings this to the Aurora drivers might want to mention that:

Christian came by the JS pit a few minutes ago to ask about this.
There seemed to be general agreement to take a green changeset from
Friday and merge that to Aurora.


--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
@paulbiggar

Chris Leary

unread,
Jul 6, 2011, 5:19:48 PM7/6/11
to Jeff Walden, Andreas Gal, Benjamin Smedberg, Brendan Eich, Dave Herman, dev-tech-js-en...@lists.mozilla.org
On Wed, Jul 6, 2011 at 12:57 AM, Jeff Walden <jwa...@mit.edu> wrote:
> If he were suddenly not
> here next Monday, or some particular day we wanted a merge to happen, who
> would pick up the slack? How would it happen?
> Ideally we all should have a fair inkling of how to do this.

Just wrote https://developer.mozilla.org/en/SpiderMonkey/Merging_TraceMonkey_Repo

- Leary

Chris Leary

unread,
Jul 6, 2011, 8:07:21 PM7/6/11
to Paul Biggar, Jason Orendorff, Boris Zbarsky, dev-tech-js-en...@lists.mozilla.org
On Wed, Jul 6, 2011 at 12:45 PM, Paul Biggar <pbi...@mozilla.com> wrote:
> Christian came by the JS pit a few minutes ago to ask about this.
> There seemed to be general agreement to take a green changeset from
> Friday and merge that to Aurora.

http://hg.mozilla.org/releases/mozilla-aurora/rev/75552dfd25c2

We can go cancel our mozilla-aurora ?s now, feel free to add the merge
changeset link.

- Leary

Reply all
Reply to author
Forward
0 new messages