[webkit-dev] Request for position on FedCM (was WebID)

[Sam Goto via webkit-dev]

Hi WebKit-Dev,
We've been working on a Web Platform API that allows users to login to
websites with their federated accounts in a privacy preserving manner.

We've been calling it FedCM (was WebID) and we would like to hear what you
think!

Here is our explainer, spec and a brief introduction:


   - explainer 
   - specification 
   - TPAC2021
   
presentation
   (video introduction)


WDYT?

One specific area of coordination is its relationship to the Login Status
API and the Storage Access API. We'd be happy to learn more from you about
both of these APIs and how they relate to FedCM, but just as a starting
point, here [1
,
2
]
is our interpretation of each.

Looking forward to hearing from you,

Sam
Various other past reviews:

   - WebID? 
   - WICG thread
   

   - Federation and Browsers Workshop
   
   - Intent To Prototype
   

   - FedID CG 
   - early TAG review 
   - Ready For Trial
   
   - spec TAG review 
   - Mozilla's Standards Position
   
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] GitHub Labels

[Ryosuke Niwa via webkit-dev]

On Thu, Mar 10, 2022 at 10:49 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hey folks,
>
> We’re in the final stage of bringing up support for GitHub pull-requests.
> To support this effort, we’re starting to add labels to our project. We
> intend to use labels as a replacement for commit-queue flags and
> Product/Component/Version fields in bugzilla. Before our tools are too
> reliant on specific label names, we wanted to solicit feedback to see if
> folks had specific opinions on certain categories. Bellow I have some
> preliminary thoughts on what labels the project would find helpful:
>
> EWS and Merge-Queue labels:
> merge-queue (green): Applied to send a PR to merge-queue (equivalent of a
> modern cq+)
> fast-merge-queue (green): Applied to send a PR to merge-queue, but skip
> building and testing
>

I don't like "fast merge" because who doesn't want fast merging? It doesn't
convey why that's different from regular merge, or why using this option
may not be always desirable. I also don't think "queue" adds much
information about these flags.

So why not simply:

   - merge
   - untested-merge or testless-merge?

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] GitHub Labels

[Jonathan Bedard via webkit-dev]

Hey folks,

We’re in the final stage of bringing up support for GitHub pull-requests. To 
support this effort, we’re starting to add labels to our project. We intend to 
use labels as a replacement for commit-queue flags and 
Product/Component/Version fields in bugzilla. Before our tools are too reliant 
on specific label names, we wanted to solicit feedback to see if folks had 
specific opinions on certain categories. Bellow I have some preliminary 
thoughts on what labels the project would find helpful: 

EWS and Merge-Queue labels:
merge-queue (green): Applied to send a PR to merge-queue (equivalent of 
a modern cq+)
fast-merge-queue (green): Applied to send a PR to merge-queue, but skip 
building and testing
merging-blocked (purple): Applied to prevent a change from being merged 
(equivalent of a modern cq-)

Component labels (all white)
Use our existing bugzilla component labels and descriptions

Version labels (all grey)
Use our existing bugzilla version labels and descriptions

Misc:
regression (red): Addresses a problem that did not previously exist

It’s worth noting that changing a labels name does apply to existing labels of 
that name, so any decisions we make now can be modified without too much 
disruption.

Existing labels:
https://github.com/WebKit/WebKit/labels 


Excited to here your thoughts,
Jonathan___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev