https://docs.google.com/spreadsheets/d/10i30CFUPJM7snz0xX3czFJeBh2tNwjwjtI409DQw3x0
Thank you to everyone who's been filling in the worksheet. Good start.
Almost halfway there!
It would be great to get to 75% complete by end of day Monday.
If you've not looked at the sheet, do it; your knowledge
On 1/22/16 3:52 PM, Gregory Szorc wrote:
I would say that pushing cherry-picked commits for review that depend on
other commits not in the commit's ancestry is just wrong. If you pushed
this to Try, it would fail. So why are you pushing a "bad" commit/tree for
review? If your commits depend on so
On Fri, Jan 22, 2016 at 11:24 AM, Ehsan Akhgari
wrote:
> On 2016-01-22 2:10 PM, Gregory Szorc wrote:
>
>> On Fri, Jan 22, 2016 at 7:30 AM, Boris Zbarsky wrote:
>>
>> On 1/22/16 10:08 AM, Andrew Halberstadt wrote:
>>>
>>> In the end, it's on the reviewer. If the patch is complicated, has open
>>>
On Fri, Jan 22, 2016 at 9:50 AM, Adam Roach wrote:
> On 1/22/16 06:12, Daniel Minor wrote:
>
>> Another difference is that sheriffs require a try run before they will
>> land
>> a patch flagged "checkin-needed." In Bug 1239281 we're proposing to
>> implement this requirement for autolanding.
>>
>
I think if we want to experiment in MozReview, we still need to reflect
something in Bugzilla that kills the nuance and avoids unexpected landings
from folks trying to be helpful. It's not hard or risky to add one
additional flag (making review/feedback/land all available) and let
MozReview do mos
On Fri, Jan 22, 2016 at 11:24 AM, Bobby Holley
wrote:
>
>
> On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey wrote:
>
>> Early in the next release cycle I plan to land a patch that will remove
>> nsPIDOMWindow in favor of two separate types for inner and outer windows
>> (fittingly, called nsPIDOMWind
On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey wrote:
> Early in the next release cycle I plan to land a patch that will remove
> nsPIDOMWindow in favor of two separate types for inner and outer windows
> (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter) I'll also make
> changes to the XPIDL
On 2016-01-22 2:10 PM, Gregory Szorc wrote:
On Fri, Jan 22, 2016 at 7:30 AM, Boris Zbarsky wrote:
On 1/22/16 10:08 AM, Andrew Halberstadt wrote:
In the end, it's on the reviewer. If the patch is complicated, has open
dependencies or looks like it might cause problems, as a reviewer I'm
not g
On 2016-01-22 12:07 PM, Armen Zambrano G. wrote:
We're now running side by side Linux x64 debug test jobs inside of
docker on TaskCluster [1]
Where could I add instructions on how to run jobs running inside of
docker? (mdn? the tree? else?)
MDN please. Docker is going to going to be important fo
This was startling to me at first, but on further reflection, I'd like
to caution against reacting for the wrong reasons.
One driver for our current workflows is that the patch attached to
bugzilla is rarely what actually landed. With things that go through
mozreview, that need no longer be th
On Fri, Jan 22, 2016 at 7:30 AM, Boris Zbarsky wrote:
> On 1/22/16 10:08 AM, Andrew Halberstadt wrote:
>
>> In the end, it's on the reviewer. If the patch is complicated, has open
>> dependencies or looks like it might cause problems, as a reviewer I'm
>> not going to land it no matter what. If i
We're now running side by side Linux x64 debug test jobs inside of
docker on TaskCluster [1]
Where could I add instructions on how to run jobs running inside of
docker? (mdn? the tree? else?)
regards,
Armen
[1]
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=tc%20linu
On 22/01/16 10:30 AM, Boris Zbarsky wrote:
On 1/22/16 10:08 AM, Andrew Halberstadt wrote:
In the end, it's on the reviewer. If the patch is complicated, has open
dependencies or looks like it might cause problems, as a reviewer I'm
not going to land it no matter what. If it's simple and self-con
They will continue to implement nsIDOMWindow just like they do
nsIDOMWindowInternal. We're simply not going to use it for anything.
- Kyle
On Fri, Jan 22, 2016 at 7:53 AM, Dave Townsend
wrote:
> Does this mean that window objects will no longer implement
> nsIDOMWindow (at least as far as JS i
Does this mean that window objects will no longer implement
nsIDOMWindow (at least as far as JS is concerned)? Querying for
nsIDOMWindow is something add-ons do a lot and I'd expect to see a lot
of add-ons break if we changed that.
On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey wrote:
> Early in the
On 1/22/16 10:08 AM, Andrew Halberstadt wrote:
In the end, it's on the reviewer. If the patch is complicated, has open
dependencies or looks like it might cause problems, as a reviewer I'm
not going to land it no matter what. If it's simple and self-contained,
why not?
There is no obvious indic
On 22/01/16 02:12 AM, Gregory Szorc wrote:
On Thu, Jan 21, 2016 at 10:37 PM, Mike Connor wrote:
Like Greg, I'm a big fan of reviewer-lands-if-ready. It's a huge
simplification of workflow, saves developers time, and lets machines do
work instead of humans. That said, I don't think we should be
On 22/01/16 12:20 AM, Nicholas Nethercote wrote:
On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc wrote:
I've gotten into the habit of just landing things if I r+ them and I think
they are ready to land. This has startled a few people because it is a major
role reversal of how we've done things
On 1/22/16 06:12, Daniel Minor wrote:
Another difference is that sheriffs require a try run before they will land
a patch flagged "checkin-needed." In Bug 1239281 we're proposing to
implement this requirement for autolanding.
I'm always wary of using tools to enforce policy, since you frequentl
checkin? is also used for large multi-patch bugs that land parts at
different times.
On Fri, Jan 22, 2016 at 3:38 PM, Paolo Amadini
wrote:
> On 1/22/2016 2:00 PM, Mark Hammond wrote:
>
>> (Hopefully) related - what exactly is the "checkin?" flag for?
>>
>
> As far as I understand, it's used toge
On Fri, Jan 22, 2016 at 8:00 AM, Andreas Tolfsen wrote:
> Overall I think this idea makes sense. Is it your intention that the
> try run should be 100% complete, or just that one exists and is
> associated with the review? In some cases I find myself invoking
> Autoland when I feel reasonably c
On 22/01/2016 6:12 PM, Gregory Szorc wrote:
Code review will continue to shift from Bugzilla centric to MozReview
centric. And this means that Bugzilla flags mean less and less over
time. Perhaps we can solve intent in MozReview without having to change
anything in Bugzilla...
(Hopefully) relat
On 16-01-22 08:16 AM, Jared Wein wrote:
> If a patch only touches JS and CSS, could tryserver use the archive build
> implementation to generate faster try builds?
>
We could do things like that (We can tell test jobs to grab the
installer and test packages from different locations).
regards,
Ar
If a patch only touches JS and CSS, could tryserver use the archive build
implementation to generate faster try builds?
On Fri, Jan 22, 2016 at 2:16 AM, Gregory Szorc wrote:
> On Thu, Jan 21, 2016 at 10:37 PM, David Rajchenbach-Teller <
> dtel...@mozilla.com> wrote:
>
>> That sounds like it's go
Overall I think this idea makes sense. Is it your intention that the
try run should be 100% complete, or just that one exists and is
associated with the review? In some cases I find myself invoking
Autoland when I feel reasonably confident about the results.
On 22 January 2016 at 12:12, Daniel M
One of our goals for autoland is to replace the "checkin-needed" process
that is currently done manually by the sheriffs. We still have a few bugs
to fix before this is ready, for instance, approval for autolanding is not
carried forward for some users if they amend their patch.
Another difference
26 matches
Mail list logo
