Good idea, Adam. Some of those are pretty nice applications.
Technically there are difficulties around rebar3 compatibility for
NIFs. It might be easier to make them developer friendly after we
switched the whole CouchDB project to rebar3. The non-NIF apps can be
used already as source dependencies. For example: {ets_lru, {git,
"https://github.com/apache/couchdb-ets-lru.git";, {tag, "1.1.0"}}}. We
also create git tags when we update them so it's easy to refer to
those, instead of just plain commit ids. But documentation is still
missing and that would be nice to add.
Regarding releases, anyone can clone these repos and use them, but I
guess we cannot say they are ASF project "releases". Is that a correct
interpretation? Not sure if adding a disclaimer to the docs might
help, too.
There is also another direction we can take some applications like
config, for example. I think it might make sense to pull that one into
the main repo. Over the years it got tangled enough with CouchDB
specifics (couch_log, etc) that having it as separate is more of an
inconvenience than a benefit at this point.
Cheers,
-Nick
On Fri, Oct 29, 2021 at 9:53 AM Adam Kocoloski <kocol...@apache.org> wrote:
>
> 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
>
