Re: 3.2 release?
I just completed an open PR sweep on -docs, everything has an open PR in need of +1s (thanks Nick, there's more waiting!) or needs some additional help from the community. I've also created a 3.2.0 milestone in the main repo: https://github.com/apache/couchdb/milestone/8 Feel free to add anything to this that you think should be in 3.2, even if it's only aspirational. We can always pare it down if necessary. -Joan On 29/03/2021 07:51, Bessenyei Balázs Donát wrote: > 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 > wrote: >> >> I think I have read access to the COUCHDB namespace in Confluence, but not >> edit. >> >> I'll skim through `main` to see if we need to / want to backport >> things from there. >> I can also bump every PR targeted for 3.x to see if people want to get >> that content in there. >> >> Release notes: I'm really _not_ good with docs, so I'm happy there's >> someone who's doing that. >> >> >> Donat >> >> On Sun, Mar 28, 2021 at 9:20 PM Joan Touzet wrote: >>> >>> Great! Excited to get help. >>> >>> Here's the release procedure: >>> >>> https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure >>> >>> Make sure you have wiki access, your Apache creds should get you in. >>> >>> The most valuable thing you can do is make sure all of the PRs that we >>> want to land, have landed. Review all in-progress PRs and see if any >>> more need to land on 3.x. Also, look for any important backports from >>> main, though with fdb finally having landed, this will be more limited >>> than previously. This usually takes a week or two. >>> >>> I get the most enjoyment out of doing the release notes, personally, but >>> if you'd like to do it instead, go for it. Have a look at the last few >>> releases 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. 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 finish closing out any > last minute improvements, fixes, tweaks, etc. anyone wants to get in. > > -Joan "we did it before and we can do it again" Touzet
Re: [DISCUSS] API versioning redux
On 22/02/2021 20:48, Adam Kocoloski wrote: > Hi all, > > Several times in recent months we’ve had discussions on this list about > behavior changes in CouchDB 4.0 that boil down to tradeoffs between > > a) maintaining compatibility with current CouchDB APIs, and > b) capitalizing on the transactional semantics of FoundationDB > > An example would be the support for large result sets in a view response: do > we stitch together multiple transactions to support very large responses, or > provide new pagination APIs and guarantee that each response is generated > from a single isolated snapshot? > > I’d like to suggest that we “have our cake and eat it, too” by introducing > versioned APIs as previously suggested by Ilya[1]. We’d have a V3 API that > strives to maximize compatibility with CouchDB 3.x, and a V4 API that still > looks and feels like CouchDB, but introduces breaking changes where necessary > to provide well-defined transactional semantics. I think this explicit > approach to API evolution could make life easier for client library > maintainers, and also free us up to improve the API without needing to be > quite as careful about in-place backwards compatibility. > > [1]: > https://lists.apache.org/thread.html/rcc742c0fdca0363bb338b54526045720868597ea35ee6842aef174e0%40%3Cdev.couchdb.apache.org%3E > > What do you think? Cheers, Adam In general, +1, as long as the concerns raised by Bob are addressed. Namely: if I point a CouchDB 1.x-3.x client at a future CouchDB 4.0, I shouldn't be *too* surprised, and as much as possible should "just work." I've long believed that 4.0 would be a transitional version, and 5.0 would break things completely... so if 5.0 (or whatever) stops accepting "v3" syntax, or "default" changes to "v4", fine by me. Also it'd be great if this was advertised in the feature strings shown in `GET /` in some intelligent way. Maybe an array of API versions supported? -Joan
Re: GSoC 2021 participation
https://community.apache.org/gsoc.html might be of help. If you are looking to talk to other Apache projects that have done this before, you could reach out on the dev@community.a.o list. https://lists.apache.org/thread.html/r189a563fe003ad8f0e4c298e18fad4da8d4b2854bd2a5d741ae3ac45%40%3Cdev.community.apache.org%3E Note the dependency on JIRA: > All ASF projects are invited to submit their ideas to their issue tracker, > please be sure to add the labels “gsoc2021” and “mentor” so that we can > automatically include them in our list of subjects. If your project does not > 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. -Joan On 29/03/2021 01:20, Bessenyei Balázs Donát wrote: > If there are any projects that don't exceed my CouchDB / erlang / JS > knowledge, I'd make sure I'm available enough to support someone doing > a GSoC with us. > What's the workflow here? Do we have to apply as a project? Do we have > to propose projects? > I did look at "Prospective ASF mentors: read this" of [1], but I don't > see what it looks like for a project. Do we need a vote here? > > > Donat > > [1]: https://community.apache.org/gsoc.html > > On Sun, Mar 28, 2021 at 11:52 PM Joan Touzet wrote: >> >> The ASF often ends up doing GSoC. I don't think we've ever had the >> sponsor within the project for it (or for Outreachy, for that matter). >> >> The most critical part is being available on a regular basis for proper >> mentoring. If you don't think you can get that into your schedule, don't >> volunteer. Assume you will get zero support from any other developer >> (not true, but best to plan for the worst case situation...) >> >> The second most critical part is to come up with a self-contained >> project that makes sense for CouchDB. The most obvious thing to me would >> be Fauxton work, esp. as it falls into the "sweet spot" of JS >> development. I dunno how good of a target main is, given how in flux it >> is; others might have a better take on that. There's also this PR that >> never finished up: >> >> https://github.com/apache/couchdb/issues/1254 >> >> These topics are all probably too big, but maybe one of them could be >> 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 >>>
Re: [DISCUSS] API versioning redux
Thank you Adam for bringing back API versioning discussion. I think we should adopt API versioning. This would allow us to get a number of benefits: 1. It would allow clients to choose appropriate API based on explicit API version support returned response from / 2. It would allow us to run two versions of APIs on the same cluster to simplify replication of data and smoother the upgrade of client libraries 3. It would allow us to write version adapters (adapter pattern from GoF) which would convert very old API on the fly to the newest supported API. This would allow us to cleanup codebase and move ancient craft into version adapter. 4. We would be able to introduce incompatible changes into replicator protocol and adopt modern approaches to set reconciliation (IBLT or PBS based for example) 5. We would be able to drop bug compatibility approach to API evolution and introduce strict validation of input parameters 6. We can introduce openAPI specification and code generate: - input validation rules - some test cases - http endpoints code - authorization rules (https://github.com/apache/couchdb/blob/main/src/chttpd/src/chttpd_auth_request.erl#L41:L107) - handler_info rules https://github.com/apache/couchdb/blob/main/src/chttpd/src/chttpd_httpd_handlers.erl#L62:L495 7. Once we achieve 6) we can easily change the template used for code generation to adopt different http server framework. Best regards, iilyak On 2021/02/23 01:48:40, Adam Kocoloski wrote: > Hi all, > > Several times in recent months we’ve had discussions on this list about > behavior changes in CouchDB 4.0 that boil down to tradeoffs between > > a) maintaining compatibility with current CouchDB APIs, and > b) capitalizing on the transactional semantics of FoundationDB > > An example would be the support for large result sets in a view response: do > we stitch together multiple transactions to support very large responses, or > provide new pagination APIs and guarantee that each response is generated > from a single isolated snapshot? > > I’d like to suggest that we “have our cake and eat it, too” by introducing > versioned APIs as previously suggested by Ilya[1]. We’d have a V3 API that > strives to maximize compatibility with CouchDB 3.x, and a V4 API that still > looks and feels like CouchDB, but introduces breaking changes where necessary > to provide well-defined transactional semantics. I think this explicit > approach to API evolution could make life easier for client library > maintainers, and also free us up to improve the API without needing to be > quite as careful about in-place backwards compatibility. > > [1]: > https://lists.apache.org/thread.html/rcc742c0fdca0363bb338b54526045720868597ea35ee6842aef174e0%40%3Cdev.couchdb.apache.org%3E > > What do you think? Cheers, Adam
Re: 3.2 release?
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 wrote: > > I think I have read access to the COUCHDB namespace in Confluence, but not > edit. > > I'll skim through `main` to see if we need to / want to backport > things from there. > I can also bump every PR targeted for 3.x to see if people want to get > that content in there. > > Release notes: I'm really _not_ good with docs, so I'm happy there's > someone who's doing that. > > > Donat > > On Sun, Mar 28, 2021 at 9:20 PM Joan Touzet wrote: > > > > Great! Excited to get help. > > > > Here's the release procedure: > > > > https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure > > > > Make sure you have wiki access, your Apache creds should get you in. > > > > The most valuable thing you can do is make sure all of the PRs that we > > want to land, have landed. Review all in-progress PRs and see if any > > more need to land on 3.x. Also, look for any important backports from > > main, though with fdb finally having landed, this will be more limited > > than previously. This usually takes a week or two. > > > > I get the most enjoyment out of doing the release notes, personally, but > > if you'd like to do it instead, go for it. Have a look at the last few > > releases 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. > > > > > > > > > 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 finish closing out any > > >> last minute improvements, fixes, tweaks, etc. anyone wants to get in. > > >> > > >> -Joan "we did it before and we can do it again" Touzet
Re: 3.2 release?
I think I have read access to the COUCHDB namespace in Confluence, but not edit. I'll skim through `main` to see if we need to / want to backport things from there. I can also bump every PR targeted for 3.x to see if people want to get that content in there. Release notes: I'm really _not_ good with docs, so I'm happy there's someone who's doing that. Donat On Sun, Mar 28, 2021 at 9:20 PM Joan Touzet wrote: > > Great! Excited to get help. > > Here's the release procedure: > > https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure > > Make sure you have wiki access, your Apache creds should get you in. > > The most valuable thing you can do is make sure all of the PRs that we > want to land, have landed. Review all in-progress PRs and see if any > more need to land on 3.x. Also, look for any important backports from > main, though with fdb finally having landed, this will be more limited > than previously. This usually takes a week or two. > > I get the most enjoyment out of doing the release notes, personally, but > if you'd like to do it instead, go for it. Have a look at the last few > releases 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. > > > > > > 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 finish closing out any > >> last minute improvements, fixes, tweaks, etc. anyone wants to get in. > >> > >> -Joan "we did it before and we can do it again" Touzet
