On 1.x deprecation

[ermouth <er...@gmail.com>]

TLDR; Please vote -1 at @dev thread ‘[PROPOSAL] Officially deprecate
CouchDB 1.x.’ All arguments of the proposal are of no basis.

---

Hope, we all read deprecation statement from Joan. She provided one reason
directly, also several were coined in indirect way.

1. “No one is maintaining the 1.x.x branches of CouchDB anymore”

Probably that’s because they just do not need daily maintenance.

2. “Issues stack up on the tracker with no response.”

Ok, lets count. Right now couchdb github repo has 133 issues open, 11 of
them have 1.x tag.

21 of those 133 are marked with red bug tag, but none of them with 1.x. So
seems 1.x have no serious bugs, but 2.x have a pile.

How about “no response”? All 1.x issues have at least one. 33% of non-1.x
issues have zero answers. So I’d say if there exist a stack up, it’s not
related to 1.x, it’s more about 2.x.

3. “Having to patch 1.x as well as 2.x slows down the security team's
ability to push releases quickly out the door”

First, this game is two-sided. Probably, necessaty to fix not so adopted
version slowed down the team from releasing very minor upgrade for very
stable version widely used in production.

Probably, back-porting of not widely adopted 2.x features into 1.7 also
slowed process down.

Or, probably, there were no slowdown at all? As I know, that ‘slow down’
was never complained.

4. “By focusing on what we do best - supporting 2.x”

As I showed earlier it’s looks incomparably easier to support 1.x than 2.x.
As I can see from numbers, supporting 2.x issues have already taken all
focus. It happened about 1.5 years ago I’d say.

Ok, have anyone ever complained? Today I consulted a guy from BY by phone,
yesterday from IN – also privately. Classic reasonable CouchDB guys seem to
be pretty well aware they won’t have a lot of help from official support
anyway. They do not need bug fixes, they want to discuss use strategies,
solution details, they want hints and opinions how to improve things that
already works fine.

So 1.x doesn’t blur developers’ focus, unless developers start demnding
granny’s blood. Granny is still pretty healthy.

5. “I’m definitely seeing more people on 2.x these days than 1.x,
*significantly* more - both from our informal support channels as well as
through GitHub Issues and requests for paid support”

This argument is very strange. It looks like someone already have a lot of
2.x tickets and want even more. Sorry, but I don’t see how it reflects real
users distribution, I only see that 2.x is more buggy and though sells paid
support better.

---

So, as I see all above arguments for deprecation have no relation to real
accountable state of things, unless I suppose the goal is paid support.
Honestly, I can’t believe in it.

Then why deprecate?

The deprecation notice by itself breaks reputation of 1.6/1.7, which is for
now waaay more reliable than 2.x. At least 1.6 doesn’t bite unexpectedly.

I hope keeping things as is for about a year is well enough to fix most
visible 2.x issues, and then – long live 1.x.

Unfortunately I’m not subscribed to @dev and can’t reply into past proposal
thread even if get subscribed now.

So if you feel my arguments are reasonable, I ask you to cast ‘-1’ under
that proposal. Thank you.

ermouth

Re: On 1.x deprecation

[Johs Ensby <jo...@b2w.com>]

OK:)


> On 6 Jul 2018, at 12:07, ermouth <er...@gmail.com> wrote:
> 
>> Approximately how many 1.x nodes to you have in production now?
>> What is your estimated total no of users on these?
> 
> Sorry, can’t disclose this kind of info publicly.
> 
> All I can say I have zero nodes with 2.x in prod, despite we analyzed can
> we migrate several times. We can’t, 2.x just does not fit for production,
> which is well proved by Joan words about paid support requests, github
> issues and my own tests.
> 
> ermouth

Re: On 1.x deprecation

[ermouth <er...@gmail.com>]

> Approximately how many 1.x nodes to you have in production now?
> What is your estimated total no of users on these?

Sorry, can’t disclose this kind of info publicly.

All I can say I have zero nodes with 2.x in prod, despite we analyzed can
we migrate several times. We can’t, 2.x just does not fit for production,
which is well proved by Joan words about paid support requests, github
issues and my own tests.

ermouth

Re: On 1.x deprecation

[Johs Ensby <jo...@b2w.com>]

Thanks ermouth,

I agree with you that the logic behind the proposal could have been
clearer. A sunsetting announcement linked to the reliability criteria for 2.x
would have been preferable.

I value your opinions very much because I understand that you have
deployed large systems with CouchDB at the core.  If you would be so 
kind as to share numbers, answers to the following two questions would 
have been interesting.

Approximately how many 1.x nodes to you have in production now?
What is your estimated total no of users on these?

Johs


> On 6 Jul 2018, at 01:44, ermouth <er...@gmail.com> wrote:
> 
> TLDR; Please vote -1 at @dev thread ‘[PROPOSAL] Officially deprecate
> CouchDB 1.x.’ All arguments of the proposal are of no basis.
> 
> ---
> 
> Hope, we all read deprecation statement from Joan. She provided one reason
> directly, also several were coined in indirect way.
> 
> 1. “No one is maintaining the 1.x.x branches of CouchDB anymore”
> 
> Probably that’s because they just do not need daily maintenance.
> 
> 2. “Issues stack up on the tracker with no response.”
> 
> Ok, lets count. Right now couchdb github repo has 133 issues open, 11 of
> them have 1.x tag.
> 
> 21 of those 133 are marked with red bug tag, but none of them with 1.x. So
> seems 1.x have no serious bugs, but 2.x have a pile.
> 
> How about “no response”? All 1.x issues have at least one. 33% of non-1.x
> issues have zero answers. So I’d say if there exist a stack up, it’s not
> related to 1.x, it’s more about 2.x.
> 
> 3. “Having to patch 1.x as well as 2.x slows down the security team's
> ability to push releases quickly out the door”
> 
> First, this game is two-sided. Probably, necessaty to fix not so adopted
> version slowed down the team from releasing very minor upgrade for very
> stable version widely used in production.
> 
> Probably, back-porting of not widely adopted 2.x features into 1.7 also
> slowed process down.
> 
> Or, probably, there were no slowdown at all? As I know, that ‘slow down’
> was never complained.
> 
> 4. “By focusing on what we do best - supporting 2.x”
> 
> As I showed earlier it’s looks incomparably easier to support 1.x than 2.x.
> As I can see from numbers, supporting 2.x issues have already taken all
> focus. It happened about 1.5 years ago I’d say.
> 
> Ok, have anyone ever complained? Today I consulted a guy from BY by phone,
> yesterday from IN – also privately. Classic reasonable CouchDB guys seem to
> be pretty well aware they won’t have a lot of help from official support
> anyway. They do not need bug fixes, they want to discuss use strategies,
> solution details, they want hints and opinions how to improve things that
> already works fine.
> 
> So 1.x doesn’t blur developers’ focus, unless developers start demnding
> granny’s blood. Granny is still pretty healthy.
> 
> 5. “I’m definitely seeing more people on 2.x these days than 1.x,
> *significantly* more - both from our informal support channels as well as
> through GitHub Issues and requests for paid support”
> 
> This argument is very strange. It looks like someone already have a lot of
> 2.x tickets and want even more. Sorry, but I don’t see how it reflects real
> users distribution, I only see that 2.x is more buggy and though sells paid
> support better.
> 
> ---
> 
> So, as I see all above arguments for deprecation have no relation to real
> accountable state of things, unless I suppose the goal is paid support.
> Honestly, I can’t believe in it.
> 
> Then why deprecate?
> 
> The deprecation notice by itself breaks reputation of 1.6/1.7, which is for
> now waaay more reliable than 2.x. At least 1.6 doesn’t bite unexpectedly.
> 
> I hope keeping things as is for about a year is well enough to fix most
> visible 2.x issues, and then – long live 1.x.
> 
> Unfortunately I’m not subscribed to @dev and can’t reply into past proposal
> thread even if get subscribed now.
> 
> So if you feel my arguments are reasonable, I ask you to cast ‘-1’ under
> that proposal. Thank you.
> 
> ermouth

………………………………………
Johannes Ensby


Business to Web AS
Tollbugata 8, N- 0152 Oslo, Norway
+47 611 00 006 (mobile)
+47 611 00 700 (switchboard)
johs@b2w.com
www.linkedin.com/in/ensby
www.b2w.com

Re: On 1.x deprecation

[Harald Kisch <ha...@gmail.com>]

Thank you ermouth,

I am with your opinion.
I like CouchDB but I don't like how the devs behave currently.
It seems most of them do not really want to support the users and are
pushing only their own features with no respect to compatibility.
Sorry it is only how I observed the behavior back in time, as many devs
(Damien, Benoit, JChris, etc.) were leaving. What can we do to welcome them
back?
Instead of trying to welcome people, their mindsets and code to work
together on something really cool, disruptive actions take place instead of
focusing the growth of the community. I think there are a lot of devs out
there, wanting to contribute but were demotivated by something, may it be
the features, bugs, community spirit, I don't know.
Once CouchDB was kicking off and were leading the NO-SQL community. On
which killer feature do we need to work to make that happen again?
I think it is freedom, not security, exactly as Alan Cox said: "Who takes
security over freedom, deserves neither freedom nor security". And with
freedom and security I do not mean technical features in the first line. I
mean freedom more in the manner of innovation, spirit and unorthodoxy.
Using features in ways they are not supposed to be used previously, and
leave the mindset of convenience like the mindset of relational databases.
As for myself, I was bored of databases in general and found CouchDB pretty
cool because it is much more as a simple data store. Why people want
CouchDB to be a simple data store is completely out of my range. So
contributing code to it, makes no sense for me.

harald



On Fri, Jul 6, 2018 at 1:44 AM, ermouth <er...@gmail.com> wrote:

> TLDR; Please vote -1 at @dev thread ‘[PROPOSAL] Officially deprecate
> CouchDB 1.x.’ All arguments of the proposal are of no basis.
>
> ---
>
> Hope, we all read deprecation statement from Joan. She provided one reason
> directly, also several were coined in indirect way.
>
> 1. “No one is maintaining the 1.x.x branches of CouchDB anymore”
>
> Probably that’s because they just do not need daily maintenance.
>
> 2. “Issues stack up on the tracker with no response.”
>
> Ok, lets count. Right now couchdb github repo has 133 issues open, 11 of
> them have 1.x tag.
>
> 21 of those 133 are marked with red bug tag, but none of them with 1.x. So
> seems 1.x have no serious bugs, but 2.x have a pile.
>
> How about “no response”? All 1.x issues have at least one. 33% of non-1.x
> issues have zero answers. So I’d say if there exist a stack up, it’s not
> related to 1.x, it’s more about 2.x.
>
> 3. “Having to patch 1.x as well as 2.x slows down the security team's
> ability to push releases quickly out the door”
>
> First, this game is two-sided. Probably, necessaty to fix not so adopted
> version slowed down the team from releasing very minor upgrade for very
> stable version widely used in production.
>
> Probably, back-porting of not widely adopted 2.x features into 1.7 also
> slowed process down.
>
> Or, probably, there were no slowdown at all? As I know, that ‘slow down’
> was never complained.
>
> 4. “By focusing on what we do best - supporting 2.x”
>
> As I showed earlier it’s looks incomparably easier to support 1.x than 2.x.
> As I can see from numbers, supporting 2.x issues have already taken all
> focus. It happened about 1.5 years ago I’d say.
>
> Ok, have anyone ever complained? Today I consulted a guy from BY by phone,
> yesterday from IN – also privately. Classic reasonable CouchDB guys seem to
> be pretty well aware they won’t have a lot of help from official support
> anyway. They do not need bug fixes, they want to discuss use strategies,
> solution details, they want hints and opinions how to improve things that
> already works fine.
>
> So 1.x doesn’t blur developers’ focus, unless developers start demnding
> granny’s blood. Granny is still pretty healthy.
>
> 5. “I’m definitely seeing more people on 2.x these days than 1.x,
> *significantly* more - both from our informal support channels as well as
> through GitHub Issues and requests for paid support”
>
> This argument is very strange. It looks like someone already have a lot of
> 2.x tickets and want even more. Sorry, but I don’t see how it reflects real
> users distribution, I only see that 2.x is more buggy and though sells paid
> support better.
>
> ---
>
> So, as I see all above arguments for deprecation have no relation to real
> accountable state of things, unless I suppose the goal is paid support.
> Honestly, I can’t believe in it.
>
> Then why deprecate?
>
> The deprecation notice by itself breaks reputation of 1.6/1.7, which is for
> now waaay more reliable than 2.x. At least 1.6 doesn’t bite unexpectedly.
>
> I hope keeping things as is for about a year is well enough to fix most
> visible 2.x issues, and then – long live 1.x.
>
> Unfortunately I’m not subscribed to @dev and can’t reply into past proposal
> thread even if get subscribed now.
>
> So if you feel my arguments are reasonable, I ask you to cast ‘-1’ under
> that proposal. Thank you.
>
> ermouth
>