Right. Good point to clarify. We're not taking on the ownership of the
patches that need to go upstream, and my original wording could be
interpreted that way. So, we can forward the patches to Skia, for
example, but we'd be forwarding the whole conversation, that the patch
author would then continue with Skia. Once those patches are approved
in Skia, we would consider landing them ahead of a full Skia update, to
expedite things. Effectively, we'd be cherry picking that particular
change out of Skia.
On 14-Dec-16 10:41, George Wright wrote:
I'm 100% in support of this.
One thing I'd like to know though is how we're going to deal with
upstreaming patches to Skia on behalf of third parties? In my
experience, it's rarely been a case of simply submitting a patch and
having it accepted; there's normally a decent amount of engineering
effort required to make it acceptable to upstream. I think it would be
nice to have some sort of plan figured out (even if it's "people
submitting patches to us should probably consult upstream first")
before we flip the kill switch here.
On 12/13/2016 4:39 PM, Milan Sreckovic wrote:
In https://bugzilla.mozilla.org/show_bug.cgi?id=1323303, we are going
to disable the build configurations that let us leave Skia out. This
will let us simplify the code, and make things cleaner, now that it
is the only supported backend. We will take patches to Gecko (or
forward them if in Skia itself) that fix problems related to Tier 3
platforms, although we don't anticipate anything coming in for SkiaGL.
--
- Milan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
