Intention to start an [oauth] "working group"
| От | Jacob Champion |
|---|---|
| Тема | Intention to start an [oauth] "working group" |
| Дата | |
| Msg-id | CAOYmi+n5tXFTuE=khSKBGGr-OX4hbqP+ALV1yUe=gn9nbE3Hzw@mail.gmail.com обсуждение исходный текст |
| Список | pgsql-hackers |
Hi all, At pgconf.dev 2025 there was an unconference session called "Scaling PostgreSQL Development". Unfortunately, the wiki entry for it at [1] is empty, but two of the conversation topics that resonated with me were - the idea of labeling a space on the list for a particular area of development, and - the idea of pulling a document that captures some form of consensus (the "spec", if you will) out of the mailing list thread that is capturing the day-to-day development and discussion. I can't really guess how well these will work within our community. So I'd like to propose an experimental working group covering the new OAuth code. = What does that mean? = "Working group" probably carries a bunch of baggage as a term (and honestly, I wouldn't mind a better suggestion). I want something lightweight, so here's what I propose to do: - I will add "[oauth]" to feature threads I start, so people can filter on it. - I will add an "[oauth]" tag to the CF app. - I will attempt to keep a living summary on the wiki for every [oauth] feature, including ones started by other people, with some inspiration from my favorite parts of the Python PEPs [2]. And that's it. The intent is for this to be an aid for discussion and community building, rather than a silo with its own processes and politics. This experiment is not binding on others and would ideally not carry any more weight than "Jacob is trying a thing" -- though I could use a skeptic or two keeping an eye on it to ensure it stays that way, if it happens to gain momentum. And if it doesn't gain momentum, that's fine (and probably expected). OAuth might be too niche to attract much discussion. Worst case, the community will hopefully have some extra design documentation on the wiki. = Why OAuth? = I'm proposing OAuth for my experiment because - I'm quite familiar with it now :) - I expect to be doing a large fraction of the review and development on it in the short term, until it matures - it occupies a very small niche - it's security-critical - it already interacts with a maze of IETF specifications There are opportunities for improvement that I don't expect to be able to get to myself, and I want an excuse to write down what's in my head and share it outward. Honestly, OAuth is probably too narrow a focus, but IMO that's a better side to err on. I certainly don't want try to put "all of Postgres authentication" or "the protocol" under a personal experiment, though I think those could potentially be great working groups. WDYT? Is this proposal light enough that it doesn't cramp other styles? --Jacob [1] https://wiki.postgresql.org/wiki/PGConf.dev_2025_Developer_Unconference [2] https://peps.python.org/pep-0001/
В списке pgsql-hackers по дате отправления: