On 2019-08-07 12:39, Jan Lehnardt wrote: > Hi Tabeth, > > Are you interested in helping out with any of these things? > > This thread is meant more as a “who’s prepared to pick up which issue to > finish before 3.0”, not a wish-list of things that would be nice to have.
+1. We'd love your help! Sorry I didn't make that clearer - this is dev@, so I assume people getting involved in this thread are actually going to contribute their time and energy to getting things done in a timely fashion. The good news is that #1524, at least, is covered for now. > On scheduled releases, we’ve tried that in the past, and we settled on 1-2 > releases per year which fits our velocity. Quarterly releases probably exceed > what we can reasonably ship in that time. Just bugfix releases would be nice, > but the release machinery is not inconsequential, so we wanna be careful with > project resources. That said, if you wanna help, we can always do with more > release engineering help :) +1 here as well. I don't foresee us moving to quarterly releases soon - we've tried twice before and failed - but more hands are always welcome. There's been some extra special help and support from people working on alternate platform support (ARM64, PowerPC) and I expect that to pay dividends very soon. > Best > Jan > — > > > >> On 7. Aug 2019, at 18:05, Tabeth Nkangoh <tab...@tabeth.com> wrote: >> >> Hello all! >> >> >> I would argue that in addition to #1534, #1524 should definitely be part of >> 3.0. The ability to control who has access to certain documents is something >> most users would expect in 2019 at this point. Right now there's really no >> way to do this without putting a convoluted proxy to act as per-document >> access control in front of your app. >> >> >> From a user perspective a 2.X to 3.X upgrade should result in a pretty >> substantial upgrade in functionality and not necessarily code improvement >> (Erlang 22 support, and Elixir test suite for example). There are other >> things I'd recommend from the backlog but as to note dilute my personal ask, >> I'd say per document access control is a must as pretty much everyone I know >> who's using CouchDB seriously in a situation that's not neatly set-up to fit >> a database-per-user will end up inevitably implementing this themselves. >> >> >> Tabeth >> >> >> P.S. As an aside, has there been thoughts on scheduling upgrades on a time >> basis as opposed to feature basis, ala EmberJS or Ubuntu? What this would >> mean in practice is that at some cadence, e.g. 4 times a year everything >> done at that point would be wrapped up in a new version. I think this would >> help the community in that there's a steady march towards functionality >> being available for production use. This would also tighten the feedback >> loop between releases and feedback. >> >> >> ________________________________ >> From: Joan Touzet <woh...@apache.org> >> Sent: Wednesday, August 7, 2019 11:52:01 AM >> To: CouchDB Developers <dev@couchdb.apache.org> >> Subject: Getting started on CouchDB 3.0, and an introduction >> >> Hi everyone, >> >> >> >> Now that we have a path forward for FoundationDB, we also need to get >> moving on our best-and-greatest CouchDB-as-is release, namely the 3.x >> branch. >> >> If we were to cut CouchDB 3.0 from master today, we'd already have a lot >> of great new things since 2.3.1: >> >> * Partitioned DBs >> * Open PRs: https://github.com/apache/couchdb-documentation/pull/385 >> * Cloudant-donated industrial-strength IOQ replacement >> * Cloudant-donated compaction daemon replacement ("smoosh") >> * Cloudant-donated view warmer ("ken") >> * Ready for Cloudant Search, if installed separately (no recompile) >> * Native shard splitting functionality >> * Improved test suite (JavaScript -> Elixir) >> * Erlang 22 support >> * Fix for rare fsync error encountered by Postgres in 2018 >> >> But we planned for a few more things for 3.0, as you can see in the >> "Proposed 3.x" column here: >> >> https://github.com/apache/couchdb/projects/1 >> >> It would be good for us to decide which of these are making it into 3.0 >> itself. At a minimum, we need #1534. I am actively working on #1523, and >> I know Jan is actively working on #1524. >> >> There's also the backlog column - we should determine if any of those >> make sense for 3.0 as well. I see a few I'd love to have in there >> personally, but don't have the time to commit to them just now. >> >> --- >> >> Also, allow me to introduce Deni Burroughs, who has been lurking on the >> list for a while now. Deni is the dbcore Cloudant Engineering Manager, >> and she'd like to help coordinate getting 3.0 out the door. Her area of >> expertise is in non-technical project management, which is great, >> because we could use more help in keeping our cats corralled! :) >> >> She and I had a chat a few weeks ago, and now seemed like the best time >> to introduce her to the list. Please make her feel welcome! >> >> -Joan >> >
