TL;DR: Thanks for the further explanation/clarification. I (reluctantly)
agree that these concerns make sense and have nothing else to add as far as
the response goes.
On Fri, Jul 27, 2018 at 2:33 PM, Tantek Çelik
wrote:
> > The only thing worth
> > noting is that while you say there's no need
On Thu, Jul 26, 2018 at 8:57 PM, James Teh wrote:
> That all seems reasonable from a process perspective. The only thing worth
> noting is that while you say there's no need to delay for years, that may
> well be what ends up happening, and Mozilla will essentially be "blocking
> progress" on
That all seems reasonable from a process perspective. The only thing worth
noting is that while you say there's no need to delay for years, that may
well be what ends up happening, and Mozilla will essentially be "blocking
progress" on this front. We want "limited resources" to drive better
Mark, does you or anyone update the document [*1] for new contributors?
This MDN page still uses mozreview's way, and current mozreview document in
readthedocs has exactly good for new contributors, but phabricator's
document [*2] isn't good for new comer because installation steps for
Windows
On Thu, Jul 26, 2018 at 6:04 PM, James Teh wrote:
> On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron wrote:
>
>> So some comments on the ARIA charter at
>> https://www.w3.org/2018/03/draft-aria-charter :
>> ...
>> I guess it seems OK to have only one implementation
>> if there's really only going
On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron wrote:
> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :
> ...
> I guess it seems OK to have only one implementation
> if there's really only going to be one implementation on that
> platform... but
On Thu, Jul 26, 2018 at 06:31:34PM -0400, Mark Côté wrote:
> The problem there is that the review repo will be bundled and stored. We
> don't want to run another Mercurial server indefinitely. Although, if the
> parent is a public changeset (as I believe most are), we could put a link
> to that
The problem there is that the review repo will be bundled and stored. We
don't want to run another Mercurial server indefinitely. Although, if the
parent is a public changeset (as I believe most are), we could put a link
to that commit in mozilla-central somewhere.
Mark
On Thu, Jul 26, 2018 at
On Thu, Jul 26, 2018 at 9:09 AM, L. David Baron wrote:
> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :
tl;dr: We should show general support for work happening in this area
(per Jamie's email), however we should point out critical flaws in the
charter
Mark Côté writes:
> On August 20, we will remove public access to MozReview and archive
> patches. Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket. The “stub attachments” in
> Bugzilla that currently redirect to MozReview will be
On 26/07/2018 19:15, Dietrich Ayala wrote:
Why are we doing this?
The goals of this effort are to ensure that the web platform technologies we're
investing in are meeting the highest priority needs of today's designers and
developers, and to accelerate availability and maximize adoption of
Hello there!
It has been almost 3 months since our last update on the Firefox Profiler.
In that time the Performance Tools team and our awesome contributors have
made numerous improvements that will hopefully make your jobs easier, for
all of you trying to make Firefox fast, for good.
Here are
We aren't planning on archiving those to S3 buckets; that would add more
complexity, since we can't just scrape Review Board for them, and from what
we can tell not too many patches have unpublished historical context.
That said, and I forgot to mention this in my announcement, we'll be
putting a
On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté wrote:
> Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket.
I think I've asked this before, but plans were uncertain at the time:
will the history of patches (i.e. otherwise unpublished
To follow up on some previous threads, here is the plan for deprecating,
archiving, and decommissioning MozReview.
The MozReview shutdown deadline is approaching. Although enhanced
commit-series support is still in progress (see update below), MozReview
users should start familiarizing themselves
Hello! Kadir Topal and I are on the Developer Outreach team, and have spent
some time this year looking at web platform development and adoption patterns.
We presented some initial findings and recommendations at the San Francisco
workweek, and are now looking for broader feedback from the
On Monday, July 23, 2018 at 10:22:48 PM UTC-4, Boris Zbarsky wrote:
> On 7/23/18 7:36 PM, Tanushree Podder wrote:
> > Secure contexts: Yes
>
> I'm not sure what this line means here. The spec does not restrict this
> API to secure contexts, right? Do we plan to thus restrict it in our
>
So some comments on the ARIA charter at
https://www.w3.org/2018/03/draft-aria-charter :
So one concern I've heard about these charters and that I probably
share is that the ARIA charter says:
For every platform with mappings in an Accessibility API Mapping
specification, at least one
Here's an approximate equivalent for hg which doesn't require
Arcanist:
https://bitbucket.org/kmaglione/hgext/src/default/phabricator.py
It's a slightly modified version of stock hg Phabricator plugin
(which we apparently have gps to thank for inspiring) which
handles parsing bug IDs and
19 matches
Mail list logo
