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 <ermo...@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
>

Reply via email to