You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Joan Touzet <wo...@apache.org> on 2019/08/07 15:52:01 UTC
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
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Jan Lehnardt <ja...@apache.org>.
Welcome Deni! :)
* * *
Joan, thanks for writing this up. I’ll def work on #1524 and would like to get
at least a basic variant into 3.0.
Best
Jan
—
> On 7. Aug 2019, at 17:52, Joan Touzet <wo...@apache.org> wrote:
>
> 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
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Joan Touzet <wo...@apache.org>.
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 <ta...@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 <wo...@apache.org>
>> Sent: Wednesday, August 7, 2019 11:52:01 AM
>> To: CouchDB Developers <de...@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
>>
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Adam Kocoloski <ko...@apache.org>.
Thanks Deni!
When it comes to deprecating and/or removing functionality, I feel like I don’t know exactly where we stand today. We have occasionally described some of the CouchApp functionality as already being deprecated, but I’m having trouble finding any official record of that in our documentation.
I think at this juncture I would like to avoid making lots of wholesale code changes on master to remove any functionality in time for 3.0. It just increases the chances that we introduce some unexpected bug in a different bit of functionality. I think it’d be good if we could land 3.0 with
1. Clear identification of any deprecated functionality in the docs
2. Any functionality that we are actually eliminating should be removed from the docs, and perhaps the basic URL endpoints should also be removed.
I guess let’s start with: does anyone believe we are in a position to be eliminating previously-deprecated functionality in 3.0?
Adam
> On Sep 4, 2019, at 1:05 PM, Denitsa Burroughs <de...@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
> - *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 <ch...@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 <ja...@apache.org>
>>> Sent: Wednesday, August 7, 2019 12:39:01 PM
>>> To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
>>>> Sent: Wednesday, August 7, 2019 11:52:01 AM
>>>> To: CouchDB Developers <de...@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
>>>>
>>>
>>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Deni,
> On 4. Sep 2019, at 19:05, Denitsa Burroughs <de...@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 <ch...@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 <ja...@apache.org>
>>> Sent: Wednesday, August 7, 2019 12:39:01 PM
>>> To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
>>>> Sent: Wednesday, August 7, 2019 11:52:01 AM
>>>> To: CouchDB Developers <de...@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/
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Joan Touzet <wo...@apache.org>.
Hi Deni,
On 2019-09-04 13:05, Denitsa Burroughs 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 am now travelling for the next 2 weeks, mostly on Apache Software
Foundation business. I'm hoping to have time to work on this during my
down time (plane flights, evenings, etc.)
My WIP branch is here, and I've put an explanation as to where I'm at:
https://github.com/apache/couchdb/pull/2092
If someone wants to help, please say something before you do, so I don't
duplicate effort.
Thanks!
> - *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 <ch...@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 <ja...@apache.org>
>>> Sent: Wednesday, August 7, 2019 12:39:01 PM
>>> To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
>>>> Sent: Wednesday, August 7, 2019 11:52:01 AM
>>>> To: CouchDB Developers <de...@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
>>>>
>>>
>>
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Denitsa Burroughs <de...@gmail.com>.
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
- *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 <ch...@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 <ja...@apache.org>
> > Sent: Wednesday, August 7, 2019 12:39:01 PM
> > To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
> >> Sent: Wednesday, August 7, 2019 11:52:01 AM
> >> To: CouchDB Developers <de...@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
> >>
> >
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Chintan Mishra <ch...@rebhu.com>.
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 <ja...@apache.org>
> Sent: Wednesday, August 7, 2019 12:39:01 PM
> To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
>> Sent: Wednesday, August 7, 2019 11:52:01 AM
>> To: CouchDB Developers <de...@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
>>
>
RE: Getting started on CouchDB 3.0, and an introduction
Posted by Peng Hui Jiang <ji...@cn.ibm.com>.
Hey Deni,
Warmly welcome!
Peng Hui
From: Denitsa Burroughs <de...@gmail.com>
To: dev@couchdb.apache.org
Date: 2019/08/08 02:03 AM
Subject: [EXTERNAL] Re: Getting started on CouchDB 3.0, and an
introduction
Hi all -
Looking forward to working with all of you! As Joan mentioned, my specialty
is project management and I am excited to be able to help with planning and
tracking the next release.
Please review the board and let us know which items you are able to take on
for 3.0 (please assign issues to yourself to claim them). I will check in
in a few weeks to see if there are any questions and we'll start tagging
the 3.0 committed content and discuss timelines.
Thanks!
Deni
On Wed, Aug 7, 2019 at 1:19 PM Tabeth Nkangoh <ta...@tabeth.com> 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?
>
>
> 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 <ja...@apache.org>
> Sent: Wednesday, August 7, 2019 12:39:01 PM
> To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
> > Sent: Wednesday, August 7, 2019 11:52:01 AM
> > To: CouchDB Developers <de...@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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_couchdb-2Ddocumentation_pull_385&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=StHLPRMq1yy_NiU9WD1yFAy2C8IV6iFS6PVlorHBaaA&s=Y7EuDAE2UO4u1AdmBetsIoD7OyTve2Z14Dl1xkO7oCo&e=
> > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_couchdb_projects_1&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=StHLPRMq1yy_NiU9WD1yFAy2C8IV6iFS6PVlorHBaaA&s=mPQoPpbji4B1A9sNbIFVY8w4ztcLrL3fvWZSiXR9B_M&e=
> >
> > 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
> >
>
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Denitsa Burroughs <de...@gmail.com>.
Hi all -
Looking forward to working with all of you! As Joan mentioned, my specialty
is project management and I am excited to be able to help with planning and
tracking the next release.
Please review the board and let us know which items you are able to take on
for 3.0 (please assign issues to yourself to claim them). I will check in
in a few weeks to see if there are any questions and we'll start tagging
the 3.0 committed content and discuss timelines.
Thanks!
Deni
On Wed, Aug 7, 2019 at 1:19 PM Tabeth Nkangoh <ta...@tabeth.com> 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?
>
>
> 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 <ja...@apache.org>
> Sent: Wednesday, August 7, 2019 12:39:01 PM
> To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
> > Sent: Wednesday, August 7, 2019 11:52:01 AM
> > To: CouchDB Developers <de...@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
> >
>
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Tabeth Nkangoh <ta...@tabeth.com>.
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?
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 <ja...@apache.org>
Sent: Wednesday, August 7, 2019 12:39:01 PM
To: CouchDB Developers <de...@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 <ta...@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 <wo...@apache.org>
> Sent: Wednesday, August 7, 2019 11:52:01 AM
> To: CouchDB Developers <de...@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
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Jan Lehnardt <ja...@apache.org>.
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 <ta...@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 <wo...@apache.org>
> Sent: Wednesday, August 7, 2019 11:52:01 AM
> To: CouchDB Developers <de...@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
>
Re: Getting started on CouchDB 3.0, and an introduction
Posted by Tabeth Nkangoh <ta...@tabeth.com>.
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 <wo...@apache.org>
Sent: Wednesday, August 7, 2019 11:52:01 AM
To: CouchDB Developers <de...@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