Hi Deni, > On 4. Sep 2019, at 19:05, Denitsa Burroughs <denitsa.burrou...@gmail.com> > wrote: > > Hi all! > > Hope everyone has had a good couple of weeks. I wanted to follow up on the > desired/planned content for 3.0. So far, I have: > > - #1534 <https://github.com/apache/couchdb/issues/1534>, required > - #1523 <https://github.com/apache/couchdb/issues/1523>, Joan > - #1524 <https://github.com/apache/couchdb/issues/1524>, Jan
I’m making slow and steady progress here, but I can’t yet promise a final date. I know I’ll have some spare time for this at the beginning of October the latest. I think at that point, I’ll have a PR prepared that is worth reviewing by the larger dev team. Best Jan — > - *Docs:* > - couch_btree developer docs, Chintan - is there an open issue or > a PR for this? > > > Are there any other issues/bug fixes/doc changes that are in progress > and/or in plan for 3.0 that I should be tracking? Please respond with your > list(s) and projected time frames. > > Thank you! > > Deni > > > > On Thu, Aug 8, 2019 at 3:31 AM Chintan Mishra <chin...@rebhu.com> wrote: > >> >> On 07/08/19 10:49 PM, Tabeth Nkangoh wrote: >>> Hey Jan, >>> >>> >>> I am actually, though I'm not sure how much help I'd be at this point >> since I'm not super familiar with the code-base. If there's been a >> recording of a deep-dive of the codebase somewhere I'd love to see it to >> get some more familiarity. Beyond what's labeled beginner-friendly on >> GitHub is there any way to see non-documentation issues that could be done >> with someone with little familiarity? >> I am working up some developer docs. couch_btree developer docs will be >> ready in 3-4 weeks. >>> >>> >>> Regarding the scheduled releases, the quarterly release was just an >> example. Good point on the build cycle. What I was thinking was just, every >> six month in this case, just taking all commits and bundling it into a >> release. In any case I can definitely help out with any documentation stuff >> for 3.0 (for example documenting the per-access control stuff) or any of >> the other functionality. In addition if you feel there's something someone >> with some beginner erlang skill and little familiarity of the project could >> tackle with minimal guidance I'd be happy to help there too! >>> >>> >>> Tabeth >>> >>> ________________________________ >>> From: Jan Lehnardt <j...@apache.org> >>> Sent: Wednesday, August 7, 2019 12:39:01 PM >>> To: CouchDB Developers <dev@couchdb.apache.org> >>> Subject: Re: Getting started on CouchDB 3.0, and an introduction >>> >>> 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. >>> >>> 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 :) >>> >>> 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 >>>> >>> >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
