Ah! That .asf.yaml configuration is neat, thanks for pointing it out. Good point on the source releases — do you have anything in particular in mind when you talk about making it simpler for the community at large?
Adam > On Oct 28, 2021, at 10:48 PM, Joan Touzet <woh...@apache.org> wrote: > > On 28/10/2021 16:44, Adam Kocoloski wrote: >> I think we could benefit from making these projects more visible. Paul’s >> jiffy library for JSON processing is a nice counterexample where he's gotten >> non-trivial contributions from the broader Erlang community by putting a >> little distance between it and CouchDB. Do others agree? > > No opinion here, but: > >> If so, I’ve been thinking about some next steps that would help on that >> front: >> - activating GH Issues (and maybe even Discussions?) > > The only ASF thing is that we must ensure that all of the Issues traffic ends > up on a mailing list for archival purposes. (I think Infra are still working > on mirroring Discussions traffic.) > > Mirroring that traffic and enabling issues is in fact self-serve now: > > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories > > and > > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Repositoryfeatures > > If you want Discussions you have to open an Infra ticket. > >> - releases published in Hex? (bit worried about the interaction with ASF >> release requirements here) > > "Real" source releases would still have to go through voting and 3 +1 PMC > votes - this could be made simpler for the community at large. with > documentation on how to test these applications independently of CouchDB. > > Binary releases aren't "real" releases, but they would need to be paired with > actual ASF releases due to policy. No problem with them being on Hex just as > there's no problem with us being on Docker or any other binary stream, just > so long as we do the "official" dance first. > > -Joan
