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
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
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
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
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
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
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
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
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
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
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
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.
> >
> 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
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
+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
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
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
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
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
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
> >&
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
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.
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
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
>
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
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
> 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
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
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"
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
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
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
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
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
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
35 matches
Mail list logo
