Re: Reformat src files with `erlfmt` on `main`

2021-06-03 Thread Bessenyei Balázs Donát
metic and make no difference to the compiled artifacts). > > B. > > > On 2 Jun 2021, at 09:18, Bessenyei Balázs Donát wrote: > > > >> My only nose-wrinkle was at `->` being placed on its own line under some > > circumstances > > I counted too many occurren

Re: Reformat src files with `erlfmt` on `main`

2021-06-02 Thread Bessenyei Balázs Donát
at is long overdue. > > > > Agree with Donat that the formatting should be enforced by CI tools so > there’s no backsliding. Can it also be set up as a local git hook etc? > > > > B. > > > > > On 21 May 2021, at 12:46, Bessenyei Balázs Donát > wrote: > > &g

Re: Reformat src files with `erlfmt` on `main`

2021-05-21 Thread Bessenyei Balázs Donát
achine job to provide consistent > > formatting. We humans are better at other things. All in all I vote for > > adopting `erlfmt` for both 3.x and main. > > > > Also thank you Donat for providing validation scripts to make sure the > > re-formatted code compiles to the s

Reformat src files with `erlfmt` on `main`

2021-05-18 Thread Bessenyei Balázs Donát
Hi dev@couchdb, To eliminate the need for formatting-related comments and thus unnecessary cycles in PRs, I've invested a little time to see if we could use a formatter on `main` [1]. The PR reformats `.erl` files in `src` and the script [2] included shows that the compiled binaries match

Re: GSoC 2021 participation

2021-04-05 Thread Bessenyei Balázs Donát
or every consumer of data > in CouchDB to build a bespoke “follower” of the _changes feed. > > Happy to dig up answers to other questions and to make connections with Kafka > / Debezium experts where it makes sense. Cheers, > > Adam > > > On Apr 2, 2021, at 5:44 PM, Bessenye

Re: Removing "node" field from replicator "/_scheduler/{jobs | docs}"

2021-04-02 Thread Bessenyei Balázs Donát
I support removing obsolete fields from responses. I also support tracking API changes. Donat On Fri, Apr 2, 2021 at 10:23 PM Robert Newson wrote: > > +1 to removing “node” on main (but not 3.x branch). > > B. > > > On 2 Apr 2021, at 21:11, Ilya Khlopotov wrote: > > > > Hi, > > > > In FDB

Re: GSoC 2021 participation

2021-04-02 Thread Bessenyei Balázs Donát
and on that one a bit if you think > it’s worthwhile. > > Adam > > > On Mar 30, 2021, at 4:42 AM, Bessenyei Balázs Donát > > wrote: > > > > Wow, I didn't realize we are that far into the timeline. > > > > I actually don't have a well-scoped idea f

Re: [DISCUSS] API versioning redux

2021-03-30 Thread Bessenyei Balázs Donát
I'm okay with dropping the idea, I just want to make sure it's also considered. [1]: https://www.jetbrains.com/lp/python-developers-survey-2020/ [2]: https://www.tiobe.com/tiobe-index// On Tue, Mar 30, 2021 at 7:20 PM Joan Touzet wrote: > > > > On 30/03/2021 12:57, Bessenyei Balázs D

Re: [DISCUSS] API versioning redux

2021-03-30 Thread Bessenyei Balázs Donát
If we are bumping major anyways, can we just go "clean slate" and promise replication compatibility only? All that while we'd publish a migration guide that explains the differences and helps users adjust their implementations, but this way we'd get rid of some potential complexity. If we do want

Re: GSoC 2021 participation

2021-03-30 Thread Bessenyei Balázs Donát
use JIRA please contact d...@community.apache.org. > > so you'll need to post at dev@community to get included in the master list. > > Student applications start tomorrow for 2 weeks, so you'll need to get a > move on... If I'm around on chat I can try and help a bit. > > -Jo

Re: 3.2 release?

2021-03-29 Thread Bessenyei Balázs Donát
Following up on my open PR sweep: @Joan: I see that you've asked on a couple of PRs back in Oct 2020 if they are to be merged and some of them were left open. Is there any objection to closing them all? Or let's ignore them for now? Donat On Mon, Mar 29, 2021 at 11:06 AM Bessenyei Balázs Donát

Re: 3.2 release?

2021-03-29 Thread Bessenyei Balázs Donát
to see the level of detail I've been including. (Plus at least > one joke, which may or may not be funny.) I'll try and start on this > tomorrow. > > -Joan > > On 28/03/2021 14:30, Bessenyei Balázs Donát wrote: > > +1 > > > > Let me know how I can help. > >

Re: GSoC 2021 participation

2021-03-28 Thread Bessenyei Balázs Donát
> cut down to something summer-sized: > > https://github.com/apache/couchdb/projects/1 > > Thanks for taking on this initiative! I know for a fact I won't have > time this summer, or I'd agree to join you. > > -Joan > > On 28/03/2021 15:59, Bessenyei Balázs Donát wrote

GSoC 2021 participation

2021-03-28 Thread Bessenyei Balázs Donát
Hi All, I've just seen that the ASF is accepted as a mentoring organisation for GSoC 2021. Is CouchDB interested in participating? I've never done a GSoC before, but I'd certainly be interested. I'd be happy to help a student contribute to CouchDB. What do you all think? Thank you, Donat

Re: 3.2 release?

2021-03-28 Thread Bessenyei Balázs Donát
+1 Let me know how I can help. Donat On Sun, Mar 28, 2021 at 7:03 PM Joan Touzet wrote: > > Hi everyone, > > We have a number of high profile improvements to 3.x since 3.1.1 came > out. I think it's about time for 3.2. Does everyone agree? > > If so, we should start a clock for ~2 weeks to

Re: [VOTE] Set a finite default for max_attachment_size

2021-02-02 Thread Bessenyei Balázs Donát
Hi Joan, > Point of order - when we do 72-hour votes, it's best to not count weekends in that 72-hours. I remembered the 72 hours is 72 so that everyone has an opportunity to chime in regardless of their location / timezone. (Ie. so that there's at least a fraction of a weekday included for

Re: [VOTE] Set a finite default for max_attachment_size

2021-02-01 Thread Bessenyei Balázs Donát
e to anoyone who uploads > >>> attachments larger than that limit, obviously, so "assumed 1G is large > >>> enough" sounds really arbitrary to me without any factual support for > >>> that assumption. > >>> > >>> > >&g

Re: [VOTE] Set a finite default for max_attachment_size

2021-02-01 Thread Bessenyei Balázs Donát
lude it here for sake of people like me who's out of > >> the loop. > >> > >> Also 1G limit seems arbitrary - how was it choosen? > >> > >> > >> Thanks, > >> Eric > >> > >> > >> > >>> On Jan

[VOTE] Set a finite default for max_attachment_size

2021-01-27 Thread Bessenyei Balázs Donát
Hi All, In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a finite default for max_attachment_size . The PR is approved, but as per Ilya's request, I'd like to call for a lazy majority vote here. The vote will remain open for at least 72 hours from now. Please let me know if

Re: [DISCUSS] Removing erlang 19 support

2021-01-25 Thread Bessenyei Balázs Donát
are deployed on > >>> 20.3.8.something. Some of these issues were non-trivial. (I'm off today, > >>> so I don't have the time to dig into the specifics until Monday.) > >>> > >>> So my $0.02 is that: if IBM/Cloudant is ready to move to something newer > >&

[DISCUSS] Removing erlang 19 support

2021-01-22 Thread Bessenyei Balázs Donát
Hi All, CI for https://github.com/apache/couchdb-config appears to be broken. I wanted to fix it in https://github.com/apache/couchdb-config/pull/34/files , but I'm getting issues with erlang 19. Are we okay with dropping 19 support there? On a different note: are we okay with dropping erlang 19

Re: [DISCUSS] VS Code dev container?

2021-01-18 Thread Bessenyei Balázs Donát
I'm not a VS Code user, but I like the idea a lot! For this change to lower the bar for new contributors, I think it would be the best to have the change in-tree with a few lines of description in the Readme. One additional benefit I haven't seen mentioned would be the Codespaces [1] integration.

Re: [ANNOUNCE] Bessenyei Balázs Donát elected as CouchDB committer

2021-01-14 Thread Bessenyei Balázs Donát
gt; > > > > I am pleased to announce that the CouchDB Project Management Committee > > > has elected Bessenyei Balázs Donát as a CouchDB committer. > > > > > > Apache ID: bessbd > > > > > > Committers are given a binding vote in certain proj

Re: CouchDB participating in Hacktoberfest 2020?

2020-10-07 Thread Bessenyei Balázs Donát
sio > > On Wed, Oct 7, 2020 at 10:57 AM Bessenyei Balázs Donát > wrote: > > > Hi All, > > > > I was wondering if Apache CouchDB is interested in participating in > > Hacktoberfest 2020. > > Previously it was an opt-in-by-default thing, but due to recent >

CouchDB participating in Hacktoberfest 2020?

2020-10-07 Thread Bessenyei Balázs Donát
Hi All, I was wondering if Apache CouchDB is interested in participating in Hacktoberfest 2020. Previously it was an opt-in-by-default thing, but due to recent changes ( https://hacktoberfest.digitalocean.com/hacktoberfest-update ), it is now required to add a topic to the GH project or label PRs

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

2020-09-22 Thread Bessenyei Balázs Donát
Hi Peng Hui (and Garren), I think the Prometheus support would be an awesome feature! >From the e-mail it's not clear to me what would happen to the already existing endpoints mentioned (`_stats`, `_system` and `_active_tasks`). Are they going to be deprecated / removed? Or does the info become

Re: [VOTE] Release Apache CouchDB 3.1.1 (RC2)

2020-09-16 Thread Bessenyei Balázs Donát
> Why should we remove this? I don’t think it is controversial. Does that mean 3.1.1 will be released with the query parameter `buffer_response`? Nit: > 3.1.1 will not be cut unless 3 +1 votes, minimum, arrive from committers, > with no blockers by convention. According to

Re: [ANNOUNCE] Glynn Bird joins the PMC

2020-09-15 Thread Bessenyei Balázs Donát
Congrats, Glynn! Donat On Tue, 15 Sep 2020 at 15:14, Garren Smith wrote: > > Congratulations Glynn and welcome. > > On Tue, Sep 15, 2020 at 2:12 PM Andy Wenk wrote: > > > Welcome Glynn ;-) > > > > Best > > > > Andy > > -- > > Andy Wenk > > Hamburg > > > > GPG fingerprint C32E 275F BCF3 9DF6

Re: [VOTE] Release Apache CouchDB 3.1.1 (RC2)

2020-09-14 Thread Bessenyei Balázs Donát
Hi All, I've checked SHAsums and GPG signature and they are correct. I've also done some end-to-end comparison to the latest docker image and there seems to be no regression. And I'm interested to see the discussion addressing Richard Ellis' concerns as any post-release changes to the "location"

Re: Per Doc Access

2020-08-04 Thread Bessenyei Balázs Donát
On Tue, 4 Aug 2020 at 13:10, Jan Lehnardt wrote: > > Ah, there might be a misconception. Per-doc-access databases are not “more > secure” > than regular databases. They are a trade-off between additional > access-control for > additional CPU and disk resources. But it’s not a case of having a

Re: Per Doc Access

2020-08-04 Thread Bessenyei Balázs Donát
On Tue, 4 Aug 2020 at 12:34, Jan Lehnardt wrote: > > The Erlang tests are already exclusively using the HTTP API. I don’t plan > to rewrite those to Elixir, but documentation on how to use this will be > written before this is merged. The documentation before merge sounds like a good idea, thank

Re: Per Doc Access

2020-08-04 Thread Bessenyei Balázs Donát
Hey Jan, I've skimmed through the PR and the RFC and it looks good to me on a first read! I have two questions (requests, maybe) though: - do you think adding some "system-level" (elixir, I guess) tests would be valuable so that a more formalized specification (and verification) of the behavior

Re: [DISCUSS] couchdb 4.0 transactional semantics

2020-07-22 Thread Bessenyei Balázs Donát
On Tue, 21 Jul 2020 at 18:45, Jan Lehnardt wrote: > I’m not sure why a URL parameter vs. a path makes a big difference? > > Do you have an example? > > Best > Jan > — Oh, sure! OpenAPI Generator [1] and et al. for example generate Java methods (like [2] out of spec [3]) per path per verb. Java's

Re: [DISCUSS] couchdb 4.0 transactional semantics

2020-07-21 Thread Bessenyei Balázs Donát
On Tue, 21 Jul 2020 at 17:42, Jan Lehnardt wrote: > We rather don’t like to break things just because we can :) > > Do you have anything specific in mind? > > Best > Jan > — > I'm not suggesting that breaking changes should be introduced just for the fun of it :) Anyway, an example could be the

Re: [DISCUSS] couchdb 4.0 transactional semantics

2020-07-21 Thread Bessenyei Balázs Donát
I think being able to leverage FoundationDB's serializability is an awesome idea! +1 (non-binding) on all 4 points. I also support the idea of changing the API in backwards-incompatible ways if that makes things more convenient / streamlined. I wonder, does this mean other, backwards-incompatible