Re: [PROPOSAL] Officially deprecate CouchDB 1.x.

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

-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 <wo...@apache.org> 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 commits to master. (Much preferred would be to
> see people fixing the things in 2.x that prevent people migrating off
> of 1.x instead.)
> 
> SECOND: Let a thousand forks bloom. If you're looking to build a CouchDB
> 1.x fork that has baked in geo/full text search, Mango, Fauxton, and
> can run on VMS, OS/2 Warp 4, NeXTStep 3.x, and Palm, have at it. I'll
> even write a blog post about your project. (Sounds interesting!)
> 
> 
> Again, this proposal defaults to lazy consensus with a 7-day expiry
> period. CouchDB committers have binding "votes" on this proposal.
> 
> Thanks for your consideration,
> Joan "to infinity, and beyond" Touzet
> 
> 
> [1] http://couchdb.apache.org/bylaws.html#decisions
> [2] In the non-U.S. sense of the word, i.e., meaning to begin
>    consideration of a proposal.
> [3] https://s.apache.org/couchdb-1.x-issues
> [4] https://s.apache.org/wdnW