Replacing polkit JS backend

[Simon McVittie]

On Fri, 20 Oct 2017 at 16:10:24 +0100, Ikey Doherty wrote:
> Our intention is that when this work is complete and tested in Solus,
> we'll want to upstream this.

(For avoidance of doubt, I do not consider myself to be a polkit
maintainer and am not in a position to accept or reject your design
proposal. I personally think it looks like it has potential, and will
be interested to see what happens.)

I think the point at which you're ready to ship this to your users seems
considerably too late to upstream it: if the polkit maintainers are
interested in this design change in principle, but review raises design
issues in the "API" that cannot be resolved in a compatible way, then
you'll be stuck with a difficult decision between breaking compatibility
for your users, or being forever incompatible with upstream polkit
(maintaining a fork whether you wanted to be or not).

I would suggest proposing the app- and user-facing "APIs" for review as
soon as you consider them to be reasonably well-thought-out, even if
the detailed implementation is only reviewed when finished.

Of course, it is possible that the reaction will be "you touched it last,
you maintain it now" :-)

How do these keyfile-based policies compare with the old (polkit 0.105)
keyfile-based policies, which e.g. Debian and Ubuntu are still shipping?

Regards,
    smcv