anslatable for shippable and make this
easy.
I'm hoping to touch base with :wlach soon so we can figure out a good
solution to this code.
~Justin Wood (Callek)
On Tue, Mar 26, 2019 at 3:05 PM Kartikaya Gupta wrote:
> Will the change to taskcluster indexes affect mozregression?
>
>
nightly' cadence of a released product. As well
as work to remove the temporary transitional index routes I tried to add.
Feel free to find me in IRC #ci or on slack at #firefox-ci if you have any
questions or concerns.
Thank You,
~Justin Wood (Callek)
[1]
https://groups.google.co
le ask about it and
via commentary in bugs. (I also created a FAQ on the RFC for how to move
forward if you did sideload, to try and mitigate the problems this could
cause).
I'm open to other ways that I can facilitate user notification though.
~Justin Wood (Callek)
On Tue, Feb 5, 2019 at
To follow up here, this is now landed on autoland, once this merges Fennec
Nightly will no longer find new updates when it was installed outside of
Google Play.
See linked document from thread for further insight.
~Justin Wood (Callek)
On Mon, Jan 28, 2019 at 3:36 PM Justin Wood wrote
CC'ing dev-platform, since dev-planning got blackholed with my message.
-- Forwarded message -
From: Justin Wood
Date: Mon, Jan 28, 2019 at 3:36 PM
Subject: Intent to Desupport: Fennec Automated Updates (when Sideload
Installed)
To: planning , firefox-ci <
firefox...@moz
d I'm not
looking to make the call on that)
~Justin Wood (Callek)
On Thu, Jan 3, 2019 at 1:22 PM Steve Fink wrote:
> On 01/03/2019 10:07 AM, Justin Wood wrote:
> > on the specific proposal front I can envision us allowing tests to be run
> > on non-pgo builds via t
ot sure if the code maintenance burden is worth
it for the benefit but I don't hold a strong opinion there.
~Justin Wood (Callek)
On Thu, Jan 3, 2019 at 11:44 AM Andrew Halberstadt wrote:
> CC Callek
>
> How will this interact with the "shippable builds" project that Calle
tions, feel free to reach out to me/releng.
~Justin Wood (Callek)
[1] - https://en.wikipedia.org/wiki/Old_Guard
[2] - https://atlee.ca/blog/posts/migration-status-3.html
[3] - https://bugzilla.mozilla.org/show_bug.cgi?id=848284
[4] - https://bugzilla.mozilla.org/show_bug.cgi?id=1458378
[5] -
https:/
e any questions or concerns.
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
vings, currently anchoring at 10am and 10pm UTC.
This has some implication for when you may expect to see new nightlies
available in your own local timezone.
Thank You,
~Justin Wood (Callek)
Release Engineering
___
dev-platform mailing list
dev-pla
And with that, new Nightly updates are live to 100% of our userbase.
Thank you again!
~Justin Wood (Callek)
On Wed, Jul 26, 2017 at 9:17 PM, Justin Wood wrote:
> As of now we are declaring this work a success!
>
> We have unfrozen Nightly updates for 10% of our userbase right now.
them resolved ASAP.
This work was accomplished without closing the trees, so big thank you to
everyone who made this milestone possible.
~Justin Wood (Callek)
On Wed, Jul 26, 2017 at 10:54 AM, Justin Wood wrote:
> This work has now begun.
>
> On Wed, Jul 26, 2017 at 9:13 AM, Justin Wo
This work has now begun.
On Wed, Jul 26, 2017 at 9:13 AM, Justin Wood wrote:
> Hello Everyone,
>
> Just a reminder that this work will be taking place in just under
> aproximately 2 hours. We are on track to complete it as outlined.
>
> Trees may be closed during parts of
evening or sometime tomorrow.
Thank You again,
~Justin Wood (Callek)
On Fri, Jul 21, 2017 at 2:59 PM, Justin Wood wrote:
> Hello,
>
> tl;dr
>
> What: Windows opt & nightly builds switching to TaskCluster
>
> When: Wednesday, July 26th at 11:00ET
>
> Developer impact:
will just turn off Try support of Windows Buildbot Builds,
and use strictly TaskCluster.
--
Thank You,
~Justin Wood (Callek)
Mozilla Release Engineer
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Or if you must enable it in tree for try ahead of it being ready,
enable it as *tier 3* that way, those of you who *do* care can look at
results, while the rest of the dev audience can be ignorant to it, and
happily so.
(Some reasons for enable in tree ahead of ready, could be to help keep
co
s that we knew about already switched
(e.g. artifact builds)
I personally feel the investment to create a stopgap here is not worth
it, but feel free to convince chris cooper or chris atlee otherwise.
You're also free to copy in any of my points to the bug.
~Justin Wood (Callek)
On Tue, Mar
I said in irc yesterday that SeaMonkey is NOT ready yet, however I see no
reason to change the plan of record. I expect us to have a good solution in
less than a month. (As in yes go ahead and land that patch)
Thank you for the followup.
On Dec 13, 2014 1:07 PM, "Ehsan Akhgari" wrote:
> Callek,
code.
I have never further tested hg-git on windows after I encountered the
two issues above.
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
y
still is):
ssh hg.mozilla.org edit
which allowed you to delete it. We even had/have this info on MDN. The
bug exists today that the deletion does not propogate out to the
local-storage webheads.
~Justin Wood (Callek)
___
dev-platform mailin
appy from a sec standpoint if we allowed
bitbucket-hosted repos to execute arbitrary code this way.
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
on in C++
Further insight I can't easily provide unless
http://mxr.mozilla.org/build and http://mxr.mozilla.org/comm-central/ is
replicated at dxr, I can provide insight on what the req's are for both
setups (since build/ is many repos, while comm-central is 2 large repos
and a few small one
ound this change (and some relatively minor unforseen
problems with the patch, detailed in bug) that caused sheriffs to ask for this
to be backed out.
We expect wait times to return to roughly what they were as of last week for
now.
~Justin Wood (Callek)
___
That was a slip by hal, the date of the downtime is June 1, 2013, which is on a
Saturday.
Thanks for double checking,
--
~Justin Wood (Callek)
- Original Message -
From: "Kyle Huey"
To: "release"
Cc: "dev. planning" , "dev-tree-management"
Ed Morley wrote:
> On 19 January 2013 15:01:09, Ehsan Akhgari wrote:
>> dbaron posted a summary of our options on release-drivers
>
> Please can that be posted somewhere public for those of us not on
> release-drivers?
Not seeing anything that need be kept private, I'll forward a post or
two her
IRC.
--
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
id builds, a simple -p android would also trigger them.
I *believe* sfink is working on improvements in this are for us, but
being able to default-limit and overall improve try capacity/use in ways
like this is also on our radar/wanted.
--
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Mike Hommey wrote:
> On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote:
>> Rafael Ávila de Espíndola wrote:
>>>>
>>>> Actually, ICU has several options for how its data is packaged. One option
>>>> is libraries (which are no
h ICU too?
>
Not yet, there are supported Hardware models using 10.6 that *do not*
have 64 bit avaiable. Granted they are on the older end of stuff, but it
does exist.
--
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I knew the final outcome of that particular post (which is how I, and I
know many others, read the newsgroups here).
--
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
anything wrong you can
feel free to file a bug and ping us anyway, and we'll get to it as soon
as we can.
--
~Justin Wood (Callek)
John O'Duinn wrote:
> hi;
>
> We need to close the trees for 10hours on Sunday 21oct2012, from 8am-6pm
> PDT, in order to do network up
a
later cset (say a later cset IMPROVES Ts by 4% or more) would make us
think we regressed it on an earlier cset if that earlier talos run
finishes later?
Such that we set graph points by the time the test finished, not time
the push was, etc.
~Justin Wood (Callek)
_
bug
about moving talos to m-c as well, which we both agree does not belong
as an in-bug discussion -- and I do feel the move, if the talos module
owner feels is necessary should not get blocked on a need for an
external process, but I do feel we should think hard on t
Jeff Hammel wrote:
While a bit of an unfair example, our buildbot-configs fall into this
category.
IMO not unfair at all.
(p.s. to stay on topic, +1 to all else you said)
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform
Web-Technologies for your
system.
HTH,
--
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
*test* load on try, yes.
--
~Justin Wood (Callek)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
bound until you are sure comm is green"
If we had an exact date, or "right after aurora uplift in ~ 2 weeks" we
would have more leeway in getting this done for comm after you stuff
lands, but we're running out of time for a large breaking change in this
cycle ourselves.
37 matches
Mail list logo
