Hi Adam,
> On 19. Nov 2021, at 17:00, Adam Kocoloski wrote:
>
> Now that we’re getting closer to producing release candidates for some of
> these component libraries, I’m wondering about where they ought to be
> uploaded. Maybe a “components” directory alongside the top-level “source” and
>
Now that we’re getting closer to producing release candidates for some of these
component libraries, I’m wondering about where they ought to be uploaded. Maybe
a “components” directory alongside the top-level “source” and “binary”
directories that we use for CouchDB artifacts? E.g.
source/
Intriguing. Looks like Airflow is using GHCR pretty extensively alongside their
GHA-based CI. It does make good sense to me to advertise an image alongside the
repo as a Quickstart that contains all the dependencies necessary to build the
software. Not the most urgent thing, but I’ll add it to
FYI: while GH Releases is discouraged for any apache repo, GHCR is
apparently acceptable. So perhaps this is an option for your containers?
https://github.com/apache/yetus/pkgs/container/yetus
https://github.com/apache/yetus/pkgs/container/yetus-base
reference:
> On Nov 17, 2021, at 12:22 AM, Joan Touzet wrote:
>
>>> 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
>> 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
> 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
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.
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
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
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
> On Oct 29, 2021, at 4:03 PM, Nick Vatamaniuc wrote:
>
> 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.
I recall that discussion cropping up in the past. I
On 29/10/2021 09:52, Adam Kocoloski 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?
Sorry, that . should be a , :
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
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 wrote:
>
> On 28/10/2021
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
Hi,
I was doing some work on erlfdb today and I was reminded that we’ve developed a
series of Erlang applications that have no dependency on CouchDB on could be
generally useful in other Erlang applications. Some examples include:
b64url - NIF for encoding / decoding strings using a url-safe
17 matches
Mail list logo
