Re: [DISCUSS] improving visibility for CouchDB-maintained independent Erlang apps
>> Do we really think these apps are going to have a lot of churn and need a >> lot of releases? > > I could see `erlfdb` needing a regular release cadence, but I’m willing to > see what can be done to comply with the ASF regulations in a semi-automated > way. The other repos we’ve been discussing are somewhat more stable, although > part of the motivation for publishing packages is to drive more interest in > them and that could lead to more releases. > > Tangentially-related question for you: one of the CI jobs for erlfdb is using > a container image built from this Dockerfile: > > https://github.com/apache/couchdb-erlfdb/blob/main/.devcontainer/Dockerfile > > Should I publish that image as a tag in apache/couchdbci-debian, even though > it’s basically a completely different build than the other images in there? > Creating a whole new e.g. apache/erlfdbci repo for it seems like overkill, > but I’m curious to hear your thoughts. Would something like this work? > > apache/couchdbci-debian:erlfdb-erlang-24.1.4-fdb-6.3.18 > I guess you can't merge it with the other images directly? No objection to using the tagging approach you outline above, of course. But looking at other image names in the apache Docker Hub org, I think Infra would readily approve another name if you need it. -Joan
Re: [DISCUSS] improving visibility for CouchDB-maintained independent Erlang apps
> On Nov 16, 2021, at 6:05 PM, Joan Touzet wrote: > > On 16/11/2021 17:53, Joan Touzet wrote: >> On 16/11/2021 16:08, Nick Vatamaniuc wrote: >>> As for voting for making these proper releases, I am not really >>> looking forward to the SVN pushes, signing, checksumming, and >>> collecting votes for these deps. >> Scriptable, shouldn't be hard if someone has time. >>> Especially for a NIF with just 2 >>> functions in it. Wonder what can be simplified there. Can voting be >>> done in a GH release draft comments section as opposed a dev@couchdb. >> No, all votes must be on the mailing list, sorry. > > Just to add to this we're not supposed to use the GH release system for any > 'official' release, and in fact Infra is in talks with GH to have that system > disabled for all apache/* repos. I would absolutely avoid using the GH > release system as a basis for the Apache artefacts, and I'd be worried that > your scripting today could be undermined tomorrow. > > I'm not saying that's right or wrong, it's just what I've heard. If you have > concerns, take them up with Infra directly. > > Do we really think these apps are going to have a lot of churn and need a lot > of releases? I could see `erlfdb` needing a regular release cadence, but I’m willing to see what can be done to comply with the ASF regulations in a semi-automated way. The other repos we’ve been discussing are somewhat more stable, although part of the motivation for publishing packages is to drive more interest in them and that could lead to more releases. Tangentially-related question for you: one of the CI jobs for erlfdb is using a container image built from this Dockerfile: https://github.com/apache/couchdb-erlfdb/blob/main/.devcontainer/Dockerfile Should I publish that image as a tag in apache/couchdbci-debian, even though it’s basically a completely different build than the other images in there? Creating a whole new e.g. apache/erlfdbci repo for it seems like overkill, but I’m curious to hear your thoughts. Would something like this work? apache/couchdbci-debian:erlfdb-erlang-24.1.4-fdb-6.3.18 Cheers, Adam
Re: [DISCUSS] improving visibility for CouchDB-maintained independent Erlang apps
On 16/11/2021 17:53, Joan Touzet wrote: On 16/11/2021 16:08, Nick Vatamaniuc wrote: As for voting for making these proper releases, I am not really looking forward to the SVN pushes, signing, checksumming, and collecting votes for these deps. Scriptable, shouldn't be hard if someone has time. Especially for a NIF with just 2 functions in it. Wonder what can be simplified there. Can voting be done in a GH release draft comments section as opposed a dev@couchdb. No, all votes must be on the mailing list, sorry. Just to add to this we're not supposed to use the GH release system for any 'official' release, and in fact Infra is in talks with GH to have that system disabled for all apache/* repos. I would absolutely avoid using the GH release system as a basis for the Apache artefacts, and I'd be worried that your scripting today could be undermined tomorrow. I'm not saying that's right or wrong, it's just what I've heard. If you have concerns, take them up with Infra directly. Do we really think these apps are going to have a lot of churn and need a lot of releases?
Re: [DISCUSS] improving visibility for CouchDB-maintained independent Erlang apps
On 16/11/2021 16:08, Nick Vatamaniuc wrote: As for voting for making these proper releases, I am not really looking forward to the SVN pushes, signing, checksumming, and collecting votes for these deps. Scriptable, shouldn't be hard if someone has time. Especially for a NIF with just 2 functions in it. Wonder what can be simplified there. Can voting be done in a GH release draft comments section as opposed a dev@couchdb. No, all votes must be on the mailing list, sorry. What about SVN pushes, can we automate pushing the GH release .tgz artifact to SVN with a bot or something? Or does calling them "tags" instead of releases make a difference? You can automate them but you have to do the signing and signoff personally, so the best you can do is a script that you run on your machine with each release, and type in your GPG key to sign it. Thanks, -Nick On Tue, Nov 16, 2021 at 3:02 PM Adam Kocoloski wrote: Hi, I’ve spent some cycles on this work over the past few weeks and wanted to summarize my progress and propose some next steps. I focused on the following two apps: erlfdb (Erlang API for FoundationDB) b64url (Base64 encoder / decoder with URL-safe scheme) I’ve submitted PRs to implement the following functionality from my initial mail: - rebar3 compatibility - project READMEs that clarify the app is independent of (but maintained by) CouchDB - activating GH Issues I’ve also introduced some additional enhancements: - devcontainer configurations to simplify dev environment - CI using GitHub Actions to verify support for Linux + Windows and Erlang/OTP 22-24 - branch protection configurations - automated code coverage reports sent to coveralls.io In the few days since I added GH Issues to erlfdb we’ve had a request for packages on hex.pm, which was the next item on the list :) As we discussed, this community should produce official source releases upstream of any packages that get published. I’m willing to take a shot at running a simplified release process for these other repos, though I might need to “phone a friend” the first time through as I’ve never run a CouchDB release. Sound good? In the meantime, I’ve got a few PRs that could use a +1 if folks have the time: https://github.com/apache/couchdb-erlfdb/pull/35 https://github.com/apache/couchdb-erlfdb/pull/42 https://github.com/apache/couchdb-erlfdb/pull/43 https://github.com/apache/couchdb-b64url/pull/8 Cheers, Adam
Re: [DISCUSS] improving visibility for CouchDB-maintained independent Erlang apps
Nicely done, Adam! +1 for most of the PR except one. Perhaps there is a way to push the CI image to the couchdbdev account instead of your personal one. As for voting for making these proper releases, I am not really looking forward to the SVN pushes, signing, checksumming, and collecting votes for these deps. Especially for a NIF with just 2 functions in it. Wonder what can be simplified there. Can voting be done in a GH release draft comments section as opposed a dev@couchdb. What about SVN pushes, can we automate pushing the GH release .tgz artifact to SVN with a bot or something? Or does calling them "tags" instead of releases make a difference? Thanks, -Nick On Tue, Nov 16, 2021 at 3:02 PM Adam Kocoloski wrote: > > Hi, > > I’ve spent some cycles on this work over the past few weeks and wanted to > summarize my progress and propose some next steps. I focused on the following > two apps: > > erlfdb (Erlang API for FoundationDB) > b64url (Base64 encoder / decoder with URL-safe scheme) > > I’ve submitted PRs to implement the following functionality from my initial > mail: > > > - rebar3 compatibility > > - project READMEs that clarify the app is independent of (but maintained > > by) CouchDB > > - activating GH Issues > > I’ve also introduced some additional enhancements: > > - devcontainer configurations to simplify dev environment > - CI using GitHub Actions to verify support for Linux + Windows and > Erlang/OTP 22-24 > - branch protection configurations > - automated code coverage reports sent to coveralls.io > > In the few days since I added GH Issues to erlfdb we’ve had a request for > packages on hex.pm, which was the next item on the list :) As we discussed, > this community should produce official source releases upstream of any > packages that get published. I’m willing to take a shot at running a > simplified release process for these other repos, though I might need to > “phone a friend” the first time through as I’ve never run a CouchDB release. > Sound good? > > In the meantime, I’ve got a few PRs that could use a +1 if folks have the > time: > > https://github.com/apache/couchdb-erlfdb/pull/35 > https://github.com/apache/couchdb-erlfdb/pull/42 > https://github.com/apache/couchdb-erlfdb/pull/43 > https://github.com/apache/couchdb-b64url/pull/8 > > Cheers, Adam >
Re: [DISCUSS] improving visibility for CouchDB-maintained independent Erlang apps
Hi, I’ve spent some cycles on this work over the past few weeks and wanted to summarize my progress and propose some next steps. I focused on the following two apps: erlfdb (Erlang API for FoundationDB) b64url (Base64 encoder / decoder with URL-safe scheme) I’ve submitted PRs to implement the following functionality from my initial mail: > - rebar3 compatibility > - project READMEs that clarify the app is independent of (but maintained by) > CouchDB > - activating GH Issues I’ve also introduced some additional enhancements: - devcontainer configurations to simplify dev environment - CI using GitHub Actions to verify support for Linux + Windows and Erlang/OTP 22-24 - branch protection configurations - automated code coverage reports sent to coveralls.io In the few days since I added GH Issues to erlfdb we’ve had a request for packages on hex.pm, which was the next item on the list :) As we discussed, this community should produce official source releases upstream of any packages that get published. I’m willing to take a shot at running a simplified release process for these other repos, though I might need to “phone a friend” the first time through as I’ve never run a CouchDB release. Sound good? In the meantime, I’ve got a few PRs that could use a +1 if folks have the time: https://github.com/apache/couchdb-erlfdb/pull/35 https://github.com/apache/couchdb-erlfdb/pull/42 https://github.com/apache/couchdb-erlfdb/pull/43 https://github.com/apache/couchdb-b64url/pull/8 Cheers, Adam
