>
> Can we converge on a solution here ASAP? This is now holding up making
>
> Marketplace a packaged app, and I suspect it will bite us again soon.
>
>
>
> -Ben
I think everyone on that thread wants to come up with a solution to fix this.
However, I think there's just outstanding debate ma
On 4/25/13 5:45 PM, Justin Lebar wrote:
If apps are served from and signed by the marketplace, then any origin is okay
(after
review.)
I know that we rely on code review for a lot of security assurance
questions, but it seems to me that allowing /any origin/ opens us up
to attacks needlessly.
> If apps are served from and signed by the marketplace, then any origin is
> okay (after
> review.)
I know that we rely on code review for a lot of security assurance
questions, but it seems to me that allowing /any origin/ opens us up
to attacks needlessly.
Could we allow any out of a whitelis
Hi folks,
I want to raise what I believe is a relatively urgent issue with
packaged apps and web origins:
https://bugzilla.mozilla.org/show_bug.cgi?id=852720
Currently, packaged apps run in an origin that is newly minted for each
device installation, effectively a GUID that differs from d
Requesting one set of tests on one platform is a 6-10 hour turnaround for me.
- Original Message -
From: "Neil"
To: dev-platform@lists.mozilla.org
Sent: Thursday, April 25, 2013 4:36:02 PM
Subject: Re: Some data on mozilla-inbound
Justin Lebar wrote:
>Note that we don't have enough capa
Justin Lebar wrote:
Note that we don't have enough capacity to turn around current try requests
within a reasonable amount of time.
Is this because people are requesting too much because try chooser
simply isn't sufficiently descriptive for what people want?
--
Warning: May contain traces o
In this thread [1], we discussed a proposal that aimed to clean up
Windows widget code, speed up performance, and consolidate desktop and
metro logic. Thanks to everyone who participated in that thread! Based
on the input there, and an extensive discussion in #windev, the
following seems to be wha
Sorry, I must have misunderstood what you meant.
If all you're saying is that sometimes, it's good to call a meeting to
make a decision, I don't think we disagree.
On Thu, Apr 25, 2013 at 4:56 PM, Milan Sreckovic wrote:
>
>
> On 2013-04-25, at 2:07 PM, Justin Lebar wrote:
>
>>> Justin pointed o
> Chrome has a six-week development cycle like Mozilla, but they only have one
> six-week beta delay between Canary and release. So Chrome can ship a new
> feature in 6-12 weeks compared to Mozilla's 12-18 weeks.
Having three pre-release populations on two branches instead of three
pre-release
On 2013-04-25, at 2:07 PM, Justin Lebar wrote:
>> Justin pointed out his earlier post and the apparent disagreement I had with
>> it with the
>> "pick a long thread topic" example - and he has a point. I meant it as an
>> example, and
>> didn't say as much, and I meant more to focus on decis
On 4/25/13 8:20 AM, Robert Kaiser wrote:
So, for the short term, I think those two outcomes (early-beta-flag and
throttling) are the right thing to do here as we need to get that
testing in time. For the longer run we IMHO need to think again about
how we can get more people on the Aurora and eve
On 25 April 2013 20:14:10, Justin Lebar wrote:
Is this what you're saying?
* 10.6 opt tests - per-checkin (no change)
* 10.6 debug tests- reduced
* 10.7 opt tests - reduced
* 10.7 debug tests - reduced
* reduced --> m-c, m-a, m-b, m-r, esr17
Yes.
Now that I think about
> Is this what you're saying?
> * 10.6 opt tests - per-checkin (no change)
> * 10.6 debug tests- reduced
> * 10.7 opt tests - reduced
> * 10.7 debug tests - reduced
>
> * reduced --> m-c, m-a, m-b, m-r, esr17
Yes.
Now that I think about this more, maybe we should go big or
On 2013-04-25 2:39 PM, Justin Lebar wrote:
We could come to the compromise of running them on m-c, m-a, m-b and m-r. Only
this would help a lot since most of the load comes from m-i and try. We could
make it a non-by-default platform on try.
I wonder if we should do the same for debug 10.6 tes
- Original Message -
> >> We could come to the compromise of running them on m-c, m-a, m-b
> >> and m-r. Only this would help a lot since most of the load comes
> >> from m-i and try. We could make it a non-by-default platform on
> >> try.
>
> I wonder if we should do the same for debug
>> We could come to the compromise of running them on m-c, m-a, m-b and m-r.
>> Only this would help a lot since most of the load comes from m-i and try. We
>> could make it a non-by-default platform on try.
I wonder if we should do the same for debug 10.6 tests (and maybe builds).
The fact of
> We could come to the compromise of running them on m-c, m-a, m-b and m-r.
> Only this would help a lot since most of the load comes from m-i and try. We
> could make it a non-by-default platform on try.
This strategy would prevent any holes in our coverage, but accomplish the goal
of reducing
> Justin pointed out his earlier post and the apparent disagreement I had with
> it with the
> "pick a long thread topic" example - and he has a point. I meant it as an
> example, and
> didn't say as much, and I meant more to focus on decision making, and didn't
> say that
> either.
I also mea
On 2013-04-25 1:40 PM, Andreas Gal wrote:>
> How many 10.7 machines do we operate in that pool?
>
> Andreas
84 of them are 10.6
86 of them are 10.7
Unfortunately, we have a lot of them down (maybe a dozen) trying to fix
them (broken hard drives, bad memory, NIC). They don't have warranty.
On 2
It would be nice if we had data indicating how often tests fail on
just one version of MacOS, so we didn't have guess how useful having
10.6, 10.7, and 10.8 tests are. That's bug 860870. It's currently
blocked on treeherder, but maybe it should be re-prioritized, since we
keep running into cases
Justin pointed out his earlier post and the apparent disagreement I had with it
with the "pick a long thread topic" example - and he has a point. I meant it
as an example, and didn't say as much, and I meant more to focus on decision
making, and didn't say that either.
I agree the general engi
How many 10.7 machines do we operate in that pool?
Andreas
On Apr 25, 2013, at 10:30 AM, "Armen Zambrano G." wrote:
> (please follow up through mozilla.dev.planning)
>
> Hello all,
> I have recently been looking into our Mac OS X test wait times which have
> been bad for many months and prog
(please follow up through mozilla.dev.planning)
Hello all,
I have recently been looking into our Mac OS X test wait times which
have been bad for many months and progressively getting worst.
Less than 80% of test jobs on OS X 10.6 and 10.7 are able to start
within 15 minutes of being requested.
It seems as though fixing this bug for releng:
https://bugzilla.mozilla.org/show_bug.cgi?id=793989
and adding a UI for self-serve (etc..) would allow us to build/test on one
platform, then request new builds/tests for other platforms if our problem is
solved.
Every good meeting needs a conflict - a meeting about whether we should have
the platform meeting would be a great meeting. If we are too large to actually
have a meeting where something could be argued or decided, we probably don't
need that meeting.
Status meetings are useful, but as was p
With extremely limited experience of using try, I know that I would have at
times set a flag "stop as soon as you hit a first red on a platform". So, I
really like Chris' idea below, as a manual workaround, and a more powerful
solution for that. Easier said than done, I imagine...
Milan
On
Lawrence Mandel wrote:
However, I have had people tell me that they do get some value from this
meeting.
What value did they get and what role did they have at mozilla? I am
wondering if the audience for this meeting is no longer mozilla platform
engineers.
__
On 25 April 2013 16:11:59, Justin Lebar wrote:
Which specific proposals should we start with? As you say, there are dozens
of ideas out there, none with any kind of consensus behind them.
If a preponderance of options is actually the only thing standing in
the way of serious and timely work bei
- Original Message -
> On Thu, Apr 25, 2013 at 8:02 AM, Lawrence Mandel <
> lman...@mozilla.com > wrote:
> > My understanding from speaking with a few people is that the
> > platform
> > meeting was once useful to engineers.
>
> Well, part of that probably has to do with the fact that Mo
> Lawrence Mandel wrote:
> > However, I have had people tell me that they do get some value from
> > this meeting.
>
>
>
> What value did they get and what role did they have at mozilla? I am
> wondering if the audience for this meeting is no longer mozilla
> platform
> engineers.
In the meeti
On Thu, Apr 25, 2013 at 8:02 AM, Lawrence Mandel wrote:
> My understanding from speaking with a few people is that the platform
> meeting was once useful to engineers.
Well, part of that probably has to do with the fact that Mozilla used to be
a much smaller org. In 2008 most of platform enginee
Daniel Holbert schrieb:
Would this mean that Beta-channel users would see some features appear
on release-day, and then disappear a couple weeks later, and then those
same features (plus maybe some new ones) would suddenly reappear on the
next release day, and then potentially disappear again? (e
> Which specific proposals should we start with? As you say, there are dozens
> of ideas out there, none with any kind of consensus behind them.
If a preponderance of options is actually the only thing standing in
the way of serious and timely work being done by releng here, I would
be more than h
- Original Message -
> I think if we need to find reasons to keep a meeting relevant, we
> need
> to kill the meeting. Lawrence, you should just discontinue the
> meeting
> for a few weeks and see if we really need it. I bet we wont.
My understanding from speaking with a few people is
- Original Message -
> I can definitely tell you what I liked and disliked about these
> meetings, and why I stopped going to them.
>
> * Too many status updates. Putting the status updates in the wiki is
> great. Reading over them when a lot of people are listening
> synchronously is no
On 01:48, Thu, 25 Apr, Justin Lebar wrote:
One idea might be to give developers feedback on the consequences of a
particular push, e.g. the AWS cost, a proxy for "time during which
developers couldn't push" or some other measurable metric. Right now
each push probably "feels" as "expensive" as e
On 4/25/2013 1:07 AM, Ehsan Akhgari wrote:
On 2013-04-24 3:35 PM, Benjamin Smedberg wrote:
On 4/24/2013 3:13 PM, Justin Lebar wrote:
and last time I checked there's no way
to get notified when a meeting's notes are up (via RSS or e-mail or
whatever).
https://blog.mozilla.org/meeting-notes/arch
On 2013-04-25 2:42 AM, Phil Ringnalda wrote:
On 4/24/13 9:50 PM, Ehsan Akhgari wrote:
No. But that's not what I was talking about. Whether something lands
directly on try is a judgement call, and some people may be better at it
than others. As someone who has stopped using try server as a rul
On Thu, Apr 25, 2013 at 7:41 AM, Caspy7 wrote:
> I'm not a developer and so apologize if my understanding is oversimplified
> or naive.
> I had been under the impression that C++ (previously) was not being used
> at all, apart from Gecko itself, for security and stability reasons.
> Perhaps I am
On Thu, Apr 25, 2013 at 8:54 AM, Doug Turner wrote:
> I would much rather see us spend the time to curate what's important -- what
> platform people should/must read. Someone started a Reddit subgroup
> r/MozillaTech. This subgroup is much more relevant to the work that my team
> is doing than t
40 matches
Mail list logo
