Re: On 1.x deprecation
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 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) j...@b2w.com www.linkedin.com/in/ensby www.b2w.com
Re: On 1.x deprecation
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 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
Re: On 1.x deprecation
> 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
OK:) > On 6 Jul 2018, at 12:07, ermouth 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: [PROPOSAL] Officially deprecate CouchDB 1.x.
-1 A sunsetting discussion is very welcome, but this proposal is unclear, based on week arguments and a lack of data, and as decision support not the best of proposals. 1) To "table" a propoal for voting is problematic --- Joan specifically reference "non-US" meaning of the "table", which means "to begin consideration (or reconsideration) of a proposal". When listing what this proposal means i 4 points, her point 1 is the premature "kill swtich". It blocks any new or inactive developers from contributing. A proposal that is "tabled" should be revised before voted on, or you run the risk that it is a pure developer-centric decision. 2) Lack of data --- To use demand for support as a measure of usage can be misleading. 1.x users face less problems, therefore they are the easiest to support. As a minimum, the results from the recent survey should be presented to verify the support for abanoning 1.x at this stage. It would also be interesting to actively check the status of some hailmark installations like the npm Registry. 3) Lack of logic --- The argument for dropping 1.x is that: "No one is maintaining the 1.x.x branches.. By focusing [...] we can improve our release cadence" This makes no sense. There are no resources to reallocate to 2.x "to push releases quickly out the door." "avoid misleading our user base with false promises" To my knowledge, no promises have been made and complaints aired. Right now the couchdb github repo has 133 issues open 358 closed, 11 of them have 1.x tag. (2 closed). That is All the 1.x tickets could be closed with a "known issues note" explaining the decision to focus on 2.x issues. There are no red tag 1.x issues. Conclusion --- Tabeling a proposal that means: "The Apache CouchDB project will no longer make new 1.x releases." is not tabeling at all. It is a far-reaching, irreversible decision and to "sweethen" it with promises to endorce a new team or a thousand forks is really backwards. The discussion should be summed up in a final propsal whch is a less drastic sunsetting proposal to avoid spreading uncertainty amoung users and those that, while 2.x is still not bug-free, are making a forward-looking decision on what DB system to choose. Johs PS: all my opinions are IMHO, and I appreciate the efforts of the 2.x team very much > On 4 Jul 2018, at 22:51, Joan Touzet wrote: > > DISCLAIMER: This is a non-technical proposal to make a project decision. > Per our Bylaws[1], this means that it should "normally be made with lazy > consensus, or by the entire community using discussion-led > consensus-building, and not through formal voting." However, since the > intent is to make a significant policy change, this concrete proposal > should be considered as a *lazy consensus* decision with a *7 day* > timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this > thread your ample consideration. > > > I would like to table[2] a proposal to terminate official Apache support > for CouchDB 1.x. This means that: > > 1. The Apache CouchDB project will no longer make new 1.x releases. > 2. All remaining 1.x issues in JIRA and GH Issues will be closed. > 3. Everyone can continue to use 1.x as long as they want. > 4. People are welcome to continue discussing 1.x on the users@ list. > > > The reason is simple: no one is maintaining the 1.x.x branches of > CouchDB anymore. Issues stack up on the tracker[3] with no response. > Original grand plans of back-porting 2.x features such as Mango to 1.x > have not materialised. And when important security issues surface[4], > having to patch 1.x as well as 2.x slows down the security team's > ability to push releases quickly out the door. > > By focusing on what we do best - supporting 2.x and beyond with bug > fixes, new features, and ever-improving documentation and web UI - we > can improve our release cadence and avoid misleading our user base > with false promises. > > > THAT SAID: There are two important footnotes to the proposal. > > FIRST: If a group of interested maintainers start making active efforts > to improve 1.x branch upkeep, I can speak with the full authority of the > PMC to say that we'll endorse those efforts. But to un-mothball > 1.x officially should require more than 1-2 people doing occasional > bugfixing work. I'd personally want to see at least a 3-person team > making sustained contributions to 1.x before re-activating official > releases. Also, that work would need to be in-line with work currently > happening on master; I wouldn't want to see new 1.x features materialise > that don't have parallel
