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 2018/07/04 20:51:15 UTC
[PROPOSAL] Officially deprecate CouchDB 1.x.
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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Joan Touzet <wo...@apache.org>.
All:
Though this wasn't an official VOTE, the results are:
* 8 +1 votes, all from committers on the project.
* 2 -1 votes from non-committer dev@ members who would like to keep
using 1.x until they are able to safely migrate to 2.x.
The intent of the proposal was to get broad community consensus on the
approach. What I'm seeing is a disconnect between a small portion of the
community - who enjoy and appreciate CouchDB, but who are unable to
upgrade to 2.x at this time - and the developers who actually build and
release CouchDB, who are no longer prepared to support them with 1.x
releases. (As a reminder: other than a few trivial commits to prepare
security releases, the 1.x branches have had no activity since December
2015.)
While this is unfortunate, we have to recognize reality: without the
developers to support 1.x, it is dishonest and inappropriate for this
project to pretend it is still supporting CouchDB 1.x as a first class
release branch that still receives regular updates.
At this time, I think there is no choice but to discontinue 1.x security
releases. (As previously stated, there already were no other 1.x
releases planned or in the works.) In the event of a serious security
problem being disclosed to security@couchdb.apache.org, this could be
revisited on a case-by-case basis.
So what happens now?
* Our code repository at https://gitbox.apache.org/repos/asf/couchdb.git
and at https://github.com/apache/couchdb will continue to hold a
copy of the 1.x release code.
* https://couchdb.apache.org/ does not change for now. At some point
in the future, probably with the 3.0.0 release, all references to
1.x downloads will be removed. At that time, downloads of the
1.x release assets will be available only through the archive at
https://archive.apache.org/dist/couchdb/.
* All issues related to 1.x on GitHub and JIRA will be closed with
a comment stating that official 1.x support has ended. If those
issues still apply to 2.x, the issues will be updated and brought
into consideration for resolution in a future CouchDB release.
* Issues related to 1.x->2.x migration, as summarised on the user@
mailing list recently, should be prioritised for inclusion in a
new release of CouchDB *as soon as possible*.
* PRs against the 1.7.x branch are welcome for security issues,
which might trigger a 1.x release, but there is no guarantee that
such will happen.
* The next release of CouchDB will be 2.2.0, which already contains
several exciting features (such as the pluggable storage backend).
* Once again I encourage community fork projects of 1.x. The only
limitations are the Apache License v2.0, and that you can't call
your fork "CouchDB" or "Apache CouchDB".
Thank you for your time,
Joan "It's never easy to say goodbye" Touzet
----- Original Message -----
> From: "Joan Touzet" <wo...@apache.org>
> To: dev@couchdb.apache.org
> Sent: Wednesday, July 4, 2018 4:51:15 PM
> Subject: [PROPOSAL] Officially deprecate CouchDB 1.x.
>
> 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
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Paul Davis <pa...@gmail.com>.
+1
On Thu, Jul 5, 2018 at 5:18 AM Andy Wenk <an...@apache.org> wrote:
>
> +1
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> GPG public key:
> http://pgp.mit.edu/pks/lookup?op=get&search=0x45D3565377F93D29
>
>
>
> > On 5. Jul 2018, at 11:21, Garren Smith <ga...@apache.org> wrote:
> >
> > +1 to this as well. We just don't have enough dev's to do this, and I would
> > rather see us focusing on CouchDB 2.x
> >
> > On Thu, Jul 5, 2018 at 10:26 AM, Robert Samuel Newson <rn...@apache.org>
> > wrote:
> >
> >> +1
> >>
> >> I am also for the proposal to officially deprecate couchdb 1.x.
> >>
> >> I would not want to see back-porting or new feature work in 1.x even if a
> >> theoretical 3 person team were to materialise. Of course any such team that
> >> does appear could fork couchdb 1.x and work on it independently (the only
> >> caveat being that it could not be called "couchdb").
> >>
> >> I agree with Joan and Jan that we are simply recognising reality here.
> >> There is no one developing on the 1.x branch and hasn't been for ages. It
> >> is time for us to officially let it go.
> >>
> >> B.
> >>
> >>> On 5 Jul 2018, at 09:18, Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>
> >>>
> >>>> 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.
> >>>
> >>> +1
> >>>
> >>> Best
> >>> Jan
> >>> —
> >>>>
> >>>> 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
> >>>
> >>> --
> >>> Professional Support for Apache CouchDB:
> >>> https://neighbourhood.ie/couchdb-support/
> >>
> >>
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Andy Wenk <an...@apache.org>.
+1
--
Andy Wenk
Hamburg - Germany
RockIt!
GPG public key:
http://pgp.mit.edu/pks/lookup?op=get&search=0x45D3565377F93D29
> On 5. Jul 2018, at 11:21, Garren Smith <ga...@apache.org> wrote:
>
> +1 to this as well. We just don't have enough dev's to do this, and I would
> rather see us focusing on CouchDB 2.x
>
> On Thu, Jul 5, 2018 at 10:26 AM, Robert Samuel Newson <rn...@apache.org>
> wrote:
>
>> +1
>>
>> I am also for the proposal to officially deprecate couchdb 1.x.
>>
>> I would not want to see back-porting or new feature work in 1.x even if a
>> theoretical 3 person team were to materialise. Of course any such team that
>> does appear could fork couchdb 1.x and work on it independently (the only
>> caveat being that it could not be called "couchdb").
>>
>> I agree with Joan and Jan that we are simply recognising reality here.
>> There is no one developing on the 1.x branch and hasn't been for ages. It
>> is time for us to officially let it go.
>>
>> B.
>>
>>> On 5 Jul 2018, at 09:18, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>
>>>
>>>> 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.
>>>
>>> +1
>>>
>>> Best
>>> Jan
>>> —
>>>>
>>>> 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
>>>
>>> --
>>> Professional Support for Apache CouchDB:
>>> https://neighbourhood.ie/couchdb-support/
>>
>>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Garren Smith <ga...@apache.org>.
+1 to this as well. We just don't have enough dev's to do this, and I would
rather see us focusing on CouchDB 2.x
On Thu, Jul 5, 2018 at 10:26 AM, Robert Samuel Newson <rn...@apache.org>
wrote:
> +1
>
> I am also for the proposal to officially deprecate couchdb 1.x.
>
> I would not want to see back-porting or new feature work in 1.x even if a
> theoretical 3 person team were to materialise. Of course any such team that
> does appear could fork couchdb 1.x and work on it independently (the only
> caveat being that it could not be called "couchdb").
>
> I agree with Joan and Jan that we are simply recognising reality here.
> There is no one developing on the 1.x branch and hasn't been for ages. It
> is time for us to officially let it go.
>
> B.
>
> > On 5 Jul 2018, at 09:18, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >
> >
> >> 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.
> >
> > +1
> >
> > Best
> > Jan
> > —
> >>
> >> 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
> >
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
>
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Robert Samuel Newson <rn...@apache.org>.
+1
I am also for the proposal to officially deprecate couchdb 1.x.
I would not want to see back-porting or new feature work in 1.x even if a theoretical 3 person team were to materialise. Of course any such team that does appear could fork couchdb 1.x and work on it independently (the only caveat being that it could not be called "couchdb").
I agree with Joan and Jan that we are simply recognising reality here. There is no one developing on the 1.x branch and hasn't been for ages. It is time for us to officially let it go.
B.
> On 5 Jul 2018, at 09:18, Jan Lehnardt <ja...@apache.org> wrote:
>
>
>
>> 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.
>
> +1
>
> Best
> Jan
> —
>>
>> 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
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Jan Lehnardt <ja...@apache.org>.
> 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.
+1
Best
Jan
—
>
> 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
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Roger that,
over and out.
Johs
> On 8 Jul 2018, at 17:58, Jan Lehnardt <ja...@apache.org> wrote:
>
> There might be a misunderstanding of what is required to keep 1.x from being deprecated.
>
> It is not a detailed plan, lengthy discussion, or request for features or extended support.
>
> It is people spending the time in the code and issues to prepare branches that they then produce release candidates of. The changes and issues triaged can be bugfixes and security fixes.
>
> Until the people who end up doing this, do not materialise, there is little sense in further discussions, as merely making requests for work and not putting in the work are a decent waste of everybody’s time.
>
> Note how number of users/downloads/etc doesn’t factor into the above.
>
> But while we are at it, from 75 responses to the CouchDB survey so far, we have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130 people). Note that multiple answers were possible, so the 1.x operators might also run 2.x.
>
> Those numbers and the trend along with everything else, I’m confident in deprecating 1.x. 1.x is a fine piece of software and existing installations of it will continue to run just fine, but this project is moving on.
>
> Best
> Jan
> —
>
>> On 8. Jul 2018, at 14:59, Johs Ensby <jo...@b2w.com> wrote:
>>
>> Thanks Joan,
>>
>> Your take on the data is
>>> To me the data is more proof that asking to keep 1.x on a lifeline is
>>> serving a vanishingly small amount of users.
>>
>>
>> I see no proof in the data and I disagree with respect how to best go about "serving a vanishingly small amount of users."
>>
>> My take on the data is guesswork, but I would love to see someone tare it down with data:
>>
>> 1) Millions have played with CouchDB (we are now left with a vanishingly small amount of these)
>> 2) Tens of thousands of servers are running with CouchDB today
>> (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention to upgrade, however, not actual upgrade)
>> 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being strong.
>> 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not been heard in this discussion yet
>> 5) Regarding developer activity and experimentation, the spikes connected to releases are interesting:
>> -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant spike that I don't know the background for.
>> -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know much about the sysops' plans to upgrade
>>
>> Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>>>> Thanks for the offer. Before writing up a full paper, what would
>>>>> your first 3 acts be?
>> I thought you wanted me to hold my horses and do this step by step
>> It would be a bit akward to start discussing the point 2-3 until having feeback on my intentions.
>> Should I proceed to point 1?
>>
>> I still think your proposal, as it was "tabled" had been better without the first what-it-means-point, which is a far-reaching decision with unclear benefit.
>> Also, I think the result of the recent user survey should be published to support the decision making.
>>
>> Johs
>>
>>
>>> On 7 Jul 2018, at 19:18, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> Johs Ensby wrote:
>>>> Thanks for this, Joan
>>>>
>>>> You must have put a lot time and effort into this and it is _highly
>>>> appreciated_.
>>>
>>> You're welcome.
>>>
>>>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>>>> like a
>>>> nice place to follow the trend.
>>>
>>> For a limited amount of data, compared to how popular the binary
>>> distributions from bintray.com are, yes.
>>>
>>> If Infra is able to give us access to the archived closer.lua data,
>>> we should be able to get a better picture of relative popularity,
>>> at least for people who click through https://couchdb.apache.org/ to
>>> download the tarball.
>>>
>>>> What is in second column, download
>>>> time?
>>>
>>> The script that generates the file is at:
>>>
>>> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
>>>
>>> That field is generated on line 464, which is grabbing the final octet
>>> of the IP address for uniqueness. This can help de-duplicate data, or
>>> look for "ballot-stuffing" by someone trying to make one download or the
>>> other look more popular. ;)
>>>
>>>> Although it is hard to compile totals out of this, the fact that the
>>>> numbers are
>>>> small is a fact.
>>>
>>> Again, compared to the binary downloads. Including the Docker downloads
>>> (which do not separate by version #, which is why I haven't included them
>>> in my email) there are 30+ million downloads of CouchDB in the wild.
>>>
>>> To me the data is more proof that asking to keep 1.x on a lifeline is
>>> serving a vanishingly small amount of users.
>>>
>>>> Lost of upside and few people to deal with as the
>>>> base,
>>>> which means that anyone who value CouchDB today can make a huge
>>>> impact, relatively speeking.
>>>
>>> In terms of people making a large impact, it's more about the total
>>> number of contributors and committers to the project. As a PMC member,
>>> I want to see more contributors and committers who are interested in
>>> making CouchDB better, not in publicity hounds who just want to pad
>>> their resume by working on a high-profile OSS project. (Not pointing
>>> fingers at you, just thinking out loud.)
>>>
>>>> Thanks also for this response:
>>>>> Thanks for the offer. Before writing up a full paper, what would
>>>>> your
>>>>> first 3 acts be?
>>>> 1) State my intentions, for feedback
>>>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>>>> 3) Table an outline
>>>
>>> In terms of 1.x scope, my first choice is to end support for it.
>>> Every single committer has voted +1 on this proposal so far; only you
>>> and one other dev have cast non-binding votes against it.
>>>
>>> If there is sufficient interest to continue with 1.x, the primary
>>> need is for someone to maintain it for security patches only. This
>>> would need to be established committer(s) on the project who would
>>> be available rapidly to patch and spin new releases if and when any
>>> security issues are raised by external reporters confidentially.
>>>
>>> If there's even more interest beyond that, then the only scope
>>> I can see is for bug fixes based on GitHub issue tracker posts, or
>>> at the very most, back ports of any 2.x features or changes that
>>> will make the migration to 2.x easier. This might include many
>>> deprecation warnings we talked about at one point.
>>>
>>> I don't want to see branched development on 1.x that adds new
>>> 1.x-only features, or back ports of major new 2.x functionality
>>> like Mango or clustering.
>>>
>>> I don't speak for the rest of the PMC on this.
>>>
>>> -Joan
>>
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Roger that,
over and out.
Johs
> On 8 Jul 2018, at 17:58, Jan Lehnardt <ja...@apache.org> wrote:
>
> There might be a misunderstanding of what is required to keep 1.x from being deprecated.
>
> It is not a detailed plan, lengthy discussion, or request for features or extended support.
>
> It is people spending the time in the code and issues to prepare branches that they then produce release candidates of. The changes and issues triaged can be bugfixes and security fixes.
>
> Until the people who end up doing this, do not materialise, there is little sense in further discussions, as merely making requests for work and not putting in the work are a decent waste of everybody’s time.
>
> Note how number of users/downloads/etc doesn’t factor into the above.
>
> But while we are at it, from 75 responses to the CouchDB survey so far, we have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130 people). Note that multiple answers were possible, so the 1.x operators might also run 2.x.
>
> Those numbers and the trend along with everything else, I’m confident in deprecating 1.x. 1.x is a fine piece of software and existing installations of it will continue to run just fine, but this project is moving on.
>
> Best
> Jan
> —
>
>> On 8. Jul 2018, at 14:59, Johs Ensby <jo...@b2w.com> wrote:
>>
>> Thanks Joan,
>>
>> Your take on the data is
>>> To me the data is more proof that asking to keep 1.x on a lifeline is
>>> serving a vanishingly small amount of users.
>>
>>
>> I see no proof in the data and I disagree with respect how to best go about "serving a vanishingly small amount of users."
>>
>> My take on the data is guesswork, but I would love to see someone tare it down with data:
>>
>> 1) Millions have played with CouchDB (we are now left with a vanishingly small amount of these)
>> 2) Tens of thousands of servers are running with CouchDB today
>> (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention to upgrade, however, not actual upgrade)
>> 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being strong.
>> 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not been heard in this discussion yet
>> 5) Regarding developer activity and experimentation, the spikes connected to releases are interesting:
>> -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant spike that I don't know the background for.
>> -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know much about the sysops' plans to upgrade
>>
>> Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>>>> Thanks for the offer. Before writing up a full paper, what would
>>>>> your first 3 acts be?
>> I thought you wanted me to hold my horses and do this step by step
>> It would be a bit akward to start discussing the point 2-3 until having feeback on my intentions.
>> Should I proceed to point 1?
>>
>> I still think your proposal, as it was "tabled" had been better without the first what-it-means-point, which is a far-reaching decision with unclear benefit.
>> Also, I think the result of the recent user survey should be published to support the decision making.
>>
>> Johs
>>
>>
>>> On 7 Jul 2018, at 19:18, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> Johs Ensby wrote:
>>>> Thanks for this, Joan
>>>>
>>>> You must have put a lot time and effort into this and it is _highly
>>>> appreciated_.
>>>
>>> You're welcome.
>>>
>>>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>>>> like a
>>>> nice place to follow the trend.
>>>
>>> For a limited amount of data, compared to how popular the binary
>>> distributions from bintray.com are, yes.
>>>
>>> If Infra is able to give us access to the archived closer.lua data,
>>> we should be able to get a better picture of relative popularity,
>>> at least for people who click through https://couchdb.apache.org/ to
>>> download the tarball.
>>>
>>>> What is in second column, download
>>>> time?
>>>
>>> The script that generates the file is at:
>>>
>>> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
>>>
>>> That field is generated on line 464, which is grabbing the final octet
>>> of the IP address for uniqueness. This can help de-duplicate data, or
>>> look for "ballot-stuffing" by someone trying to make one download or the
>>> other look more popular. ;)
>>>
>>>> Although it is hard to compile totals out of this, the fact that the
>>>> numbers are
>>>> small is a fact.
>>>
>>> Again, compared to the binary downloads. Including the Docker downloads
>>> (which do not separate by version #, which is why I haven't included them
>>> in my email) there are 30+ million downloads of CouchDB in the wild.
>>>
>>> To me the data is more proof that asking to keep 1.x on a lifeline is
>>> serving a vanishingly small amount of users.
>>>
>>>> Lost of upside and few people to deal with as the
>>>> base,
>>>> which means that anyone who value CouchDB today can make a huge
>>>> impact, relatively speeking.
>>>
>>> In terms of people making a large impact, it's more about the total
>>> number of contributors and committers to the project. As a PMC member,
>>> I want to see more contributors and committers who are interested in
>>> making CouchDB better, not in publicity hounds who just want to pad
>>> their resume by working on a high-profile OSS project. (Not pointing
>>> fingers at you, just thinking out loud.)
>>>
>>>> Thanks also for this response:
>>>>> Thanks for the offer. Before writing up a full paper, what would
>>>>> your
>>>>> first 3 acts be?
>>>> 1) State my intentions, for feedback
>>>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>>>> 3) Table an outline
>>>
>>> In terms of 1.x scope, my first choice is to end support for it.
>>> Every single committer has voted +1 on this proposal so far; only you
>>> and one other dev have cast non-binding votes against it.
>>>
>>> If there is sufficient interest to continue with 1.x, the primary
>>> need is for someone to maintain it for security patches only. This
>>> would need to be established committer(s) on the project who would
>>> be available rapidly to patch and spin new releases if and when any
>>> security issues are raised by external reporters confidentially.
>>>
>>> If there's even more interest beyond that, then the only scope
>>> I can see is for bug fixes based on GitHub issue tracker posts, or
>>> at the very most, back ports of any 2.x features or changes that
>>> will make the migration to 2.x easier. This might include many
>>> deprecation warnings we talked about at one point.
>>>
>>> I don't want to see branched development on 1.x that adds new
>>> 1.x-only features, or back ports of major new 2.x functionality
>>> like Mango or clustering.
>>>
>>> I don't speak for the rest of the PMC on this.
>>>
>>> -Joan
>>
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Jan Lehnardt <ja...@apache.org>.
There might be a misunderstanding of what is required to keep 1.x from being deprecated.
It is not a detailed plan, lengthy discussion, or request for features or extended support.
It is people spending the time in the code and issues to prepare branches that they then produce release candidates of. The changes and issues triaged can be bugfixes and security fixes.
Until the people who end up doing this, do not materialise, there is little sense in further discussions, as merely making requests for work and not putting in the work are a decent waste of everybody’s time.
Note how number of users/downloads/etc doesn’t factor into the above.
But while we are at it, from 75 responses to the CouchDB survey so far, we have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130 people). Note that multiple answers were possible, so the 1.x operators might also run 2.x.
Those numbers and the trend along with everything else, I’m confident in deprecating 1.x. 1.x is a fine piece of software and existing installations of it will continue to run just fine, but this project is moving on.
Best
Jan
—
> On 8. Jul 2018, at 14:59, Johs Ensby <jo...@b2w.com> wrote:
>
> Thanks Joan,
>
> Your take on the data is
>> To me the data is more proof that asking to keep 1.x on a lifeline is
>> serving a vanishingly small amount of users.
>
>
> I see no proof in the data and I disagree with respect how to best go about "serving a vanishingly small amount of users."
>
> My take on the data is guesswork, but I would love to see someone tare it down with data:
>
> 1) Millions have played with CouchDB (we are now left with a vanishingly small amount of these)
> 2) Tens of thousands of servers are running with CouchDB today
> (20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention to upgrade, however, not actual upgrade)
> 3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being strong.
> 4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not been heard in this discussion yet
> 5) Regarding developer activity and experimentation, the spikes connected to releases are interesting:
> -- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant spike that I don't know the background for.
> -- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know much about the sysops' plans to upgrade
>
> Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>>> Thanks for the offer. Before writing up a full paper, what would
>>>> your first 3 acts be?
> I thought you wanted me to hold my horses and do this step by step
> It would be a bit akward to start discussing the point 2-3 until having feeback on my intentions.
> Should I proceed to point 1?
>
> I still think your proposal, as it was "tabled" had been better without the first what-it-means-point, which is a far-reaching decision with unclear benefit.
> Also, I think the result of the recent user survey should be published to support the decision making.
>
> Johs
>
>
>> On 7 Jul 2018, at 19:18, Joan Touzet <wo...@apache.org> wrote:
>>
>> Johs Ensby wrote:
>>> Thanks for this, Joan
>>>
>>> You must have put a lot time and effort into this and it is _highly
>>> appreciated_.
>>
>> You're welcome.
>>
>>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>>> like a
>>> nice place to follow the trend.
>>
>> For a limited amount of data, compared to how popular the binary
>> distributions from bintray.com are, yes.
>>
>> If Infra is able to give us access to the archived closer.lua data,
>> we should be able to get a better picture of relative popularity,
>> at least for people who click through https://couchdb.apache.org/ to
>> download the tarball.
>>
>>> What is in second column, download
>>> time?
>>
>> The script that generates the file is at:
>>
>> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
>>
>> That field is generated on line 464, which is grabbing the final octet
>> of the IP address for uniqueness. This can help de-duplicate data, or
>> look for "ballot-stuffing" by someone trying to make one download or the
>> other look more popular. ;)
>>
>>> Although it is hard to compile totals out of this, the fact that the
>>> numbers are
>>> small is a fact.
>>
>> Again, compared to the binary downloads. Including the Docker downloads
>> (which do not separate by version #, which is why I haven't included them
>> in my email) there are 30+ million downloads of CouchDB in the wild.
>>
>> To me the data is more proof that asking to keep 1.x on a lifeline is
>> serving a vanishingly small amount of users.
>>
>>> Lost of upside and few people to deal with as the
>>> base,
>>> which means that anyone who value CouchDB today can make a huge
>>> impact, relatively speeking.
>>
>> In terms of people making a large impact, it's more about the total
>> number of contributors and committers to the project. As a PMC member,
>> I want to see more contributors and committers who are interested in
>> making CouchDB better, not in publicity hounds who just want to pad
>> their resume by working on a high-profile OSS project. (Not pointing
>> fingers at you, just thinking out loud.)
>>
>>> Thanks also for this response:
>>>> Thanks for the offer. Before writing up a full paper, what would
>>>> your
>>>> first 3 acts be?
>>> 1) State my intentions, for feedback
>>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>>> 3) Table an outline
>>
>> In terms of 1.x scope, my first choice is to end support for it.
>> Every single committer has voted +1 on this proposal so far; only you
>> and one other dev have cast non-binding votes against it.
>>
>> If there is sufficient interest to continue with 1.x, the primary
>> need is for someone to maintain it for security patches only. This
>> would need to be established committer(s) on the project who would
>> be available rapidly to patch and spin new releases if and when any
>> security issues are raised by external reporters confidentially.
>>
>> If there's even more interest beyond that, then the only scope
>> I can see is for bug fixes based on GitHub issue tracker posts, or
>> at the very most, back ports of any 2.x features or changes that
>> will make the migration to 2.x easier. This might include many
>> deprecation warnings we talked about at one point.
>>
>> I don't want to see branched development on 1.x that adds new
>> 1.x-only features, or back ports of major new 2.x functionality
>> like Mango or clustering.
>>
>> I don't speak for the rest of the PMC on this.
>>
>> -Joan
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Thanks Joan,
Your take on the data is
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
I see no proof in the data and I disagree with respect how to best go about "serving a vanishingly small amount of users."
My take on the data is guesswork, but I would love to see someone tare it down with data:
1) Millions have played with CouchDB (we are now left with a vanishingly small amount of these)
2) Tens of thousands of servers are running with CouchDB today
(20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention to upgrade, however, not actual upgrade)
3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being strong.
4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not been heard in this discussion yet
5) Regarding developer activity and experimentation, the spikes connected to releases are interesting:
-- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant spike that I don't know the background for.
-- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know much about the sysops' plans to upgrade
Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your first 3 acts be?
I thought you wanted me to hold my horses and do this step by step
It would be a bit akward to start discussing the point 2-3 until having feeback on my intentions.
Should I proceed to point 1?
I still think your proposal, as it was "tabled" had been better without the first what-it-means-point, which is a far-reaching decision with unclear benefit.
Also, I think the result of the recent user survey should be published to support the decision making.
Johs
> On 7 Jul 2018, at 19:18, Joan Touzet <wo...@apache.org> wrote:
>
> Johs Ensby wrote:
>> Thanks for this, Joan
>>
>> You must have put a lot time and effort into this and it is _highly
>> appreciated_.
>
> You're welcome.
>
>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>> like a
>> nice place to follow the trend.
>
> For a limited amount of data, compared to how popular the binary
> distributions from bintray.com are, yes.
>
> If Infra is able to give us access to the archived closer.lua data,
> we should be able to get a better picture of relative popularity,
> at least for people who click through https://couchdb.apache.org/ to
> download the tarball.
>
>> What is in second column, download
>> time?
>
> The script that generates the file is at:
>
> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
>
> That field is generated on line 464, which is grabbing the final octet
> of the IP address for uniqueness. This can help de-duplicate data, or
> look for "ballot-stuffing" by someone trying to make one download or the
> other look more popular. ;)
>
>> Although it is hard to compile totals out of this, the fact that the
>> numbers are
>> small is a fact.
>
> Again, compared to the binary downloads. Including the Docker downloads
> (which do not separate by version #, which is why I haven't included them
> in my email) there are 30+ million downloads of CouchDB in the wild.
>
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
>
>> Lost of upside and few people to deal with as the
>> base,
>> which means that anyone who value CouchDB today can make a huge
>> impact, relatively speeking.
>
> In terms of people making a large impact, it's more about the total
> number of contributors and committers to the project. As a PMC member,
> I want to see more contributors and committers who are interested in
> making CouchDB better, not in publicity hounds who just want to pad
> their resume by working on a high-profile OSS project. (Not pointing
> fingers at you, just thinking out loud.)
>
>> Thanks also for this response:
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your
>>> first 3 acts be?
>> 1) State my intentions, for feedback
>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>> 3) Table an outline
>
> In terms of 1.x scope, my first choice is to end support for it.
> Every single committer has voted +1 on this proposal so far; only you
> and one other dev have cast non-binding votes against it.
>
> If there is sufficient interest to continue with 1.x, the primary
> need is for someone to maintain it for security patches only. This
> would need to be established committer(s) on the project who would
> be available rapidly to patch and spin new releases if and when any
> security issues are raised by external reporters confidentially.
>
> If there's even more interest beyond that, then the only scope
> I can see is for bug fixes based on GitHub issue tracker posts, or
> at the very most, back ports of any 2.x features or changes that
> will make the migration to 2.x easier. This might include many
> deprecation warnings we talked about at one point.
>
> I don't want to see branched development on 1.x that adds new
> 1.x-only features, or back ports of major new 2.x functionality
> like Mango or clustering.
>
> I don't speak for the rest of the PMC on this.
>
> -Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Thanks Joan,
Your take on the data is
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
I see no proof in the data and I disagree with respect how to best go about "serving a vanishingly small amount of users."
My take on the data is guesswork, but I would love to see someone tare it down with data:
1) Millions have played with CouchDB (we are now left with a vanishingly small amount of these)
2) Tens of thousands of servers are running with CouchDB today
(20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year indicate intention to upgrade, however, not actual upgrade)
3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity being strong.
4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they have not been heard in this discussion yet
5) Regarding developer activity and experimentation, the spikes connected to releases are interesting:
-- 2,237 downloads of 1.7.1 for Windows on the same day early January is a significant spike that I don't know the background for.
-- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we don't know much about the sysops' plans to upgrade
Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your first 3 acts be?
I thought you wanted me to hold my horses and do this step by step
It would be a bit akward to start discussing the point 2-3 until having feeback on my intentions.
Should I proceed to point 1?
I still think your proposal, as it was "tabled" had been better without the first what-it-means-point, which is a far-reaching decision with unclear benefit.
Also, I think the result of the recent user survey should be published to support the decision making.
Johs
> On 7 Jul 2018, at 19:18, Joan Touzet <wo...@apache.org> wrote:
>
> Johs Ensby wrote:
>> Thanks for this, Joan
>>
>> You must have put a lot time and effort into this and it is _highly
>> appreciated_.
>
> You're welcome.
>
>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>> like a
>> nice place to follow the trend.
>
> For a limited amount of data, compared to how popular the binary
> distributions from bintray.com are, yes.
>
> If Infra is able to give us access to the archived closer.lua data,
> we should be able to get a better picture of relative popularity,
> at least for people who click through https://couchdb.apache.org/ to
> download the tarball.
>
>> What is in second column, download
>> time?
>
> The script that generates the file is at:
>
> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
>
> That field is generated on line 464, which is grabbing the final octet
> of the IP address for uniqueness. This can help de-duplicate data, or
> look for "ballot-stuffing" by someone trying to make one download or the
> other look more popular. ;)
>
>> Although it is hard to compile totals out of this, the fact that the
>> numbers are
>> small is a fact.
>
> Again, compared to the binary downloads. Including the Docker downloads
> (which do not separate by version #, which is why I haven't included them
> in my email) there are 30+ million downloads of CouchDB in the wild.
>
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
>
>> Lost of upside and few people to deal with as the
>> base,
>> which means that anyone who value CouchDB today can make a huge
>> impact, relatively speeking.
>
> In terms of people making a large impact, it's more about the total
> number of contributors and committers to the project. As a PMC member,
> I want to see more contributors and committers who are interested in
> making CouchDB better, not in publicity hounds who just want to pad
> their resume by working on a high-profile OSS project. (Not pointing
> fingers at you, just thinking out loud.)
>
>> Thanks also for this response:
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your
>>> first 3 acts be?
>> 1) State my intentions, for feedback
>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>> 3) Table an outline
>
> In terms of 1.x scope, my first choice is to end support for it.
> Every single committer has voted +1 on this proposal so far; only you
> and one other dev have cast non-binding votes against it.
>
> If there is sufficient interest to continue with 1.x, the primary
> need is for someone to maintain it for security patches only. This
> would need to be established committer(s) on the project who would
> be available rapidly to patch and spin new releases if and when any
> security issues are raised by external reporters confidentially.
>
> If there's even more interest beyond that, then the only scope
> I can see is for bug fixes based on GitHub issue tracker posts, or
> at the very most, back ports of any 2.x features or changes that
> will make the migration to 2.x easier. This might include many
> deprecation warnings we talked about at one point.
>
> I don't want to see branched development on 1.x that adds new
> 1.x-only features, or back ports of major new 2.x functionality
> like Mango or clustering.
>
> I don't speak for the rest of the PMC on this.
>
> -Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Robert Samuel Newson <rn...@apache.org>.
> I don't want to see branched development on 1.x that adds new
> 1.x-only features, or back ports of major new 2.x functionality
> like Mango or clustering.
I agree. Any future couchdb 1.x release will be security and bug fixes only. Not new features, not backports.
B.
> On 7 Jul 2018, at 18:18, Joan Touzet <wo...@apache.org> wrote:
>
> I don't want to see branched development on 1.x that adds new
> 1.x-only features, or back ports of major new 2.x functionality
> like Mango or clustering.
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Joan Touzet <wo...@apache.org>.
Johs Ensby wrote:
> Thanks for this, Joan
>
> You must have put a lot time and effort into this and it is _highly
> appreciated_.
You're welcome.
> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
> like a
> nice place to follow the trend.
For a limited amount of data, compared to how popular the binary
distributions from bintray.com are, yes.
If Infra is able to give us access to the archived closer.lua data,
we should be able to get a better picture of relative popularity,
at least for people who click through https://couchdb.apache.org/ to
download the tarball.
> What is in second column, download
> time?
The script that generates the file is at:
https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
That field is generated on line 464, which is grabbing the final octet
of the IP address for uniqueness. This can help de-duplicate data, or
look for "ballot-stuffing" by someone trying to make one download or the
other look more popular. ;)
> Although it is hard to compile totals out of this, the fact that the
> numbers are
> small is a fact.
Again, compared to the binary downloads. Including the Docker downloads
(which do not separate by version #, which is why I haven't included them
in my email) there are 30+ million downloads of CouchDB in the wild.
To me the data is more proof that asking to keep 1.x on a lifeline is
serving a vanishingly small amount of users.
> Lost of upside and few people to deal with as the
> base,
> which means that anyone who value CouchDB today can make a huge
> impact, relatively speeking.
In terms of people making a large impact, it's more about the total
number of contributors and committers to the project. As a PMC member,
I want to see more contributors and committers who are interested in
making CouchDB better, not in publicity hounds who just want to pad
their resume by working on a high-profile OSS project. (Not pointing
fingers at you, just thinking out loud.)
> Thanks also for this response:
> > Thanks for the offer. Before writing up a full paper, what would
> > your
> > first 3 acts be?
> 1) State my intentions, for feedback
> 2) Table my case for a 1.x branch with limit scope, again for feeback
> 3) Table an outline
In terms of 1.x scope, my first choice is to end support for it.
Every single committer has voted +1 on this proposal so far; only you
and one other dev have cast non-binding votes against it.
If there is sufficient interest to continue with 1.x, the primary
need is for someone to maintain it for security patches only. This
would need to be established committer(s) on the project who would
be available rapidly to patch and spin new releases if and when any
security issues are raised by external reporters confidentially.
If there's even more interest beyond that, then the only scope
I can see is for bug fixes based on GitHub issue tracker posts, or
at the very most, back ports of any 2.x features or changes that
will make the migration to 2.x easier. This might include many
deprecation warnings we talked about at one point.
I don't want to see branched development on 1.x that adds new
1.x-only features, or back ports of major new 2.x functionality
like Mango or clustering.
I don't speak for the rest of the PMC on this.
-Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Thanks for this, Joan
You must have put a lot time and effort into this and it is _highly appreciated_.
The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems like a
nice place to follow the trend. What is in second column, download time?
Although it is hard to compile totals out of this, the fact that the numbers are
small is a fact. Lost of upside and few people to deal with as the base,
which means that anyone who value CouchDB today can make a huge
impact, relatively speeking.
Thanks also for this response:
> Thanks for the offer. Before writing up a full paper, what would your
> first 3 acts be?
1) State my intentions, for feedback
2) Table my case for a 1.x branch with limit scope, again for feeback
3) Table an outline
Johs
> On 6 Jul 2018, at 20:01, Joan Touzet <wo...@apache.org> wrote:
>
> Hi Johs,
>
> ----- Original Message -----
>> the flaw in measuring 2.x adoption by Github issues and requests for
>> informal and paid support is that all these data points are pain
>> points,
>> not signs of error-free operation.
>> The in-production part of CouchDB based systems is not easily
>> measured, as one of the qualities of CouchDB has been zero downtime.
>> The lack of data should just add caution before using the kill
>> switch.
>
> Point taken, though there are still plenty of problems and bugs in 1.x,
> and we're not seeing people come and ask for help with them in Slack, IRC,
> on these lists or privately.
>
> Perhaps a better approach is to see the number of downloads of CouchDB
> tarballs and packages, yes? We have access to this through our bintray.com
> hosting and the apache.org mirror hierarchy.
>
> For the former, see graphs here: https://imgur.com/a/nI2bvnx
>
> Graph 1 shows downloads of the Windows package, which has the longest
> download history available. Based on this we can see that the very large
> majority of downloads of CouchDB is 2.x since the 2.0.0 release, and that
> downloads had a palpable increase with this new version. 2017 still had ~10% of
> downloads as 1.x releases, but by the time 2.1.0 released last July,
> this became background noise.
>
> With the release of 2.1.1 (see graph 2), 1.x accounts for less than 5%
> of the downloads.
>
> Graphs 3 and 4 are the same data for the Mac downloads. Total downloads
> are only 20% of the Windows downloads, but the overall trend of data is
> the same. In fact, on OSX, in 2018 downloads of 2.1.0 alone exceed
> downloads of 1.6.1, even after 2.1.1-1 was published.
>
> While I was at it, I checked download number for the new .deb/.rpm
> packages (though we only provide 2.x packages). In the year the packages
> have been available, we have ~20k downloads each on rpm and deb, with
> debian users upgrading much more aggressively to 2.1.1 from 2.0.0 than
> rpm users. See graphs 5 and 6.
>
> There is the possibility that Windows downloads are skewed, since I
> expect this is more frequently in use on desktops rather than servers.
> With 1.x packages removed from many distributions due to the age of
> SpiderMonkey 1.8.5, our best bet is to look at tarball downloads from
> the Apache mirror sites. Apache Infra logs requests through the web that
> redirect people to their nearest mirror; this is the best data we have.
> The exposed file:
>
> https://www-us.apache.org/dyn/stats/couchdb.log
>
> only covers the last 30 days; I've asked Infra if they can provide logs
> farther back for a better statistical sample.
>
> Based on this file, using this program:
>
> https://gist.github.com/wohali/899a6d6c316d2f52c7a9cec0b3b41580
>
> the count of downloads is:
>
> 0.8: 7
> 0.9: 18
> 0.11: 6
> 0.10: 6
> 1.0: 34
> 1.1: 41
> 1.2: 50
> 1.3: 19
> 1.4: 20
> 1.5: 23
> 1.6: 127
> 1.7: 201
> 2.0: 28
> 2.1: 717
>
> As expected, there is a higher 1.x count here, but it still accounts for
> less than half of the downloads, even when taking into account archived
> versions < 1.7.
>
> If we only consider 1.6, 1.7, 2.0 and 2.1, 1.x downloads account for
> 30% of tarball downloads.
>
> These download numbers are further dwarfed by the binary downloads above.
>
>
> Turning to those older distributions, installations of CouchDB 1.x on
> Debian have dropped significantly in the last couple of years:
>
> https://qa.debian.org/popcon.php?package=couchdb
>
> Ubuntu's data is skewed, due to the inclusion of CouchDB 1.1(1.2?) in
> very old versions of Ubuntu One that is no longer used. Even accounting
> for that, the data is similar, showing less than 500 active users of
> the package:
>
> #Format
> #
> #<name> is the package name;
> #<inst> is the number of people who installed this package;
> #<vote> is the number of people who use this package regularly;
> #<old> is the number of people who installed, but don't use this package
> # regularly;
> #<recent> is the number of people who upgraded this package recently;
> #<no-files> is the number of people whose entry didn't contain enough
> # information (atime and ctime were 0).
> #rank name inst vote old recent no-files (maintainer)
> 1209 couchdb-bin 835764 453 834984 18 309 (Unknown)
>
> Both distributions have removed CouchDB from their repos in the latest
> release.
>
> The very old Ubuntu Launchpad CouchDB PPA with 1.x packages has an API for
> querying the information, but I've not looked into it, because apparently
> it can take hours to gather the stats and I'm unconvinced the data will
> vary significantly from the easier-to-consume paths shown above.
>
> https://ftagada.wordpress.com/2011/01/05/ppa-stats-initial-impressions/
>
>
> Conclusion: Based on this information there is poor evidence for the
> hypothesis that CouchDB 1.x is being downloaded with any sort of frequency.
> Of course, this does not mean that people don't already have it downloaded
> and are continuing to use it on already provisioned computing resources.
>
>
>> Yes, I am volunteering for a hypothetical 3-man team. I understand
>> that
>> such a team would not pull resources allready committed to 2.x, so
>> the
>> hope would be that presently non-actice developers could be persuaded
>> to join an effort with limited, but a forward-looking scope. Noone
>> should
>> be expected to work for a branch that is doomed to die.
>> If the PMC support for and effort to keep 1.x alive can be expressed
>> clearly, I can develop a discussion paper for a hypotetical team as a
>> start.
>
> Thanks for the offer. Before writing up a full paper, what would your
> first 3 acts be?
>
> -Joan
………………………………………
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: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Joan Touzet <wo...@apache.org>.
Hi Johs,
----- Original Message -----
> the flaw in measuring 2.x adoption by Github issues and requests for
> informal and paid support is that all these data points are pain
> points,
> not signs of error-free operation.
> The in-production part of CouchDB based systems is not easily
> measured, as one of the qualities of CouchDB has been zero downtime.
> The lack of data should just add caution before using the kill
> switch.
Point taken, though there are still plenty of problems and bugs in 1.x,
and we're not seeing people come and ask for help with them in Slack, IRC,
on these lists or privately.
Perhaps a better approach is to see the number of downloads of CouchDB
tarballs and packages, yes? We have access to this through our bintray.com
hosting and the apache.org mirror hierarchy.
For the former, see graphs here: https://imgur.com/a/nI2bvnx
Graph 1 shows downloads of the Windows package, which has the longest
download history available. Based on this we can see that the very large
majority of downloads of CouchDB is 2.x since the 2.0.0 release, and that
downloads had a palpable increase with this new version. 2017 still had ~10% of
downloads as 1.x releases, but by the time 2.1.0 released last July,
this became background noise.
With the release of 2.1.1 (see graph 2), 1.x accounts for less than 5%
of the downloads.
Graphs 3 and 4 are the same data for the Mac downloads. Total downloads
are only 20% of the Windows downloads, but the overall trend of data is
the same. In fact, on OSX, in 2018 downloads of 2.1.0 alone exceed
downloads of 1.6.1, even after 2.1.1-1 was published.
While I was at it, I checked download number for the new .deb/.rpm
packages (though we only provide 2.x packages). In the year the packages
have been available, we have ~20k downloads each on rpm and deb, with
debian users upgrading much more aggressively to 2.1.1 from 2.0.0 than
rpm users. See graphs 5 and 6.
There is the possibility that Windows downloads are skewed, since I
expect this is more frequently in use on desktops rather than servers.
With 1.x packages removed from many distributions due to the age of
SpiderMonkey 1.8.5, our best bet is to look at tarball downloads from
the Apache mirror sites. Apache Infra logs requests through the web that
redirect people to their nearest mirror; this is the best data we have.
The exposed file:
https://www-us.apache.org/dyn/stats/couchdb.log
only covers the last 30 days; I've asked Infra if they can provide logs
farther back for a better statistical sample.
Based on this file, using this program:
https://gist.github.com/wohali/899a6d6c316d2f52c7a9cec0b3b41580
the count of downloads is:
0.8: 7
0.9: 18
0.11: 6
0.10: 6
1.0: 34
1.1: 41
1.2: 50
1.3: 19
1.4: 20
1.5: 23
1.6: 127
1.7: 201
2.0: 28
2.1: 717
As expected, there is a higher 1.x count here, but it still accounts for
less than half of the downloads, even when taking into account archived
versions < 1.7.
If we only consider 1.6, 1.7, 2.0 and 2.1, 1.x downloads account for
30% of tarball downloads.
These download numbers are further dwarfed by the binary downloads above.
Turning to those older distributions, installations of CouchDB 1.x on
Debian have dropped significantly in the last couple of years:
https://qa.debian.org/popcon.php?package=couchdb
Ubuntu's data is skewed, due to the inclusion of CouchDB 1.1(1.2?) in
very old versions of Ubuntu One that is no longer used. Even accounting
for that, the data is similar, showing less than 500 active users of
the package:
#Format
#
#<name> is the package name;
#<inst> is the number of people who installed this package;
#<vote> is the number of people who use this package regularly;
#<old> is the number of people who installed, but don't use this package
# regularly;
#<recent> is the number of people who upgraded this package recently;
#<no-files> is the number of people whose entry didn't contain enough
# information (atime and ctime were 0).
#rank name inst vote old recent no-files (maintainer)
1209 couchdb-bin 835764 453 834984 18 309 (Unknown)
Both distributions have removed CouchDB from their repos in the latest
release.
The very old Ubuntu Launchpad CouchDB PPA with 1.x packages has an API for
querying the information, but I've not looked into it, because apparently
it can take hours to gather the stats and I'm unconvinced the data will
vary significantly from the easier-to-consume paths shown above.
https://ftagada.wordpress.com/2011/01/05/ppa-stats-initial-impressions/
Conclusion: Based on this information there is poor evidence for the
hypothesis that CouchDB 1.x is being downloaded with any sort of frequency.
Of course, this does not mean that people don't already have it downloaded
and are continuing to use it on already provisioned computing resources.
> Yes, I am volunteering for a hypothetical 3-man team. I understand
> that
> such a team would not pull resources allready committed to 2.x, so
> the
> hope would be that presently non-actice developers could be persuaded
> to join an effort with limited, but a forward-looking scope. Noone
> should
> be expected to work for a branch that is doomed to die.
> If the PMC support for and effort to keep 1.x alive can be expressed
> clearly, I can develop a discussion paper for a hypotetical team as a
> start.
Thanks for the offer. Before writing up a full paper, what would your
first 3 acts be?
-Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Joan,
the flaw in measuring 2.x adoption by Github issues and requests for
informal and paid support is that all these data points are pain points,
not signs of error-free operation.
The in-production part of CouchDB based systems is not easily
measured, as one of the qualities of CouchDB has been zero downtime.
The lack of data should just add caution before using the kill switch.
> none have the time or inclination to continue
> working on 1.x backports, so there is no group of developers currently
> identified to fill that hypothetical 3-man team. Are you volunteering?
Yes, I am volunteering for a hypothetical 3-man team. I understand that
such a team would not pull resources allready committed to 2.x, so the
hope would be that presently non-actice developers could be persuaded
to join an effort with limited, but a forward-looking scope. Noone should
be expected to work for a branch that is doomed to die.
If the PMC support for and effort to keep 1.x alive can be expressed
clearly, I can develop a discussion paper for a hypotetical team as a start.
> Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.
I will.
br
Johs
> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>
> Hi Johs,
>
> Pull requests for 1.x continue to be welcome. But it's been almost two
> years since 2.0.0 was released - and I've seen none beyond trivial bug
> fixes. Were this proposal not to proceed, the only thing that would
> continue right now for 1.x is urgent security patches.
>
> I have already consulted with the active developers working on the
> master / 2.x branches - none have the time or inclination to continue
> working on 1.x backports, so there is no group of developers currently
> identified to fill that hypothetical 3-man team. Are you volunteering?
>
> I'm not saying "no" to backporting, but I am saying that no one has done
> so to date, and making a prediction that chances are very slim that
> it'll change in the foreseeable future.
>
> As for things in 2.x that are "must fix" before people can upgrade, I
> too would like to see pull requests for those. Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.
>
> I realize we see things differently from where we each sit, but 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. I feel
> as a result the time is right to make this proposal.
>
> Thanks for your feedback.
>
> -Joan
>
>
> ----- Original Message -----
> From: "Johs Ensby" <jo...@b2w.com>
> To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>, "Joan Touzet" <wo...@apache.org>
> Sent: Wednesday, July 4, 2018 6:06:06 PM
> Subject: Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
>
> Joan,
> thanks for your relentless effort to focus resources on moving 2.x forward.
> That said, I honestly dont see how this proposal would support your intentions
>
> 1) Migration to to 2.x would have happened already if a production ready version was available
> 2) Leaving 1.x out in the cold will not speed up migration to 2.x for the above reason
> 3) To drop support before migration is a success is a very risky move
>
> To me this is a reputation killer. When forward-looking decisions are made for or against the use of CouchDB, a minimum of two things must be in place. Confidence in the team pushing the next version forward and a commitment to keep supporting the users that want, but cannot upgrade as they wait for critical issues to be solved.
>
> My suggestion would be to move with some of the hopeful suggestions to see if some new resources would come out of the woodwork
> 1) A 3-person team should be actively encouraged into existence as a first step of a longer process
> 2) Your "no" to back-porting is reasonable if it draws resources from the main project, otherwise why curb the enthusiasm?
> 3) The decision to freeze (not abandon) should come as a consquense of 2.x fully satisfying the users with 1.x systems in production
>
> br
> Johs
>
>
>> 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
>
>
………………………………………
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: Call for "Must-fix" issues
Posted by Andrea Brancatelli <ab...@schema31.it>.
Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
On 2018-07-05 09:10, Johs Ensby wrote:
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>
>> As for things in 2.x that are "must fix" before people can upgrade, I
>> too would like to see pull requests for those. Once again, your help is
>> most welcome in this - both in identifying a definitive list of those
>> must-fix issues, as well as code towards fixing them. If you'd like
>> to help with this important work, please start a new thread.
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
Re: Call for "Must-fix" issues
Posted by Jan Lehnardt <ja...@apache.org>.
> On 5. Jul 2018, at 13:54, Mad, Pink and Dangerous to Know <pi...@mad.pink> wrote:
>
> This isn't really a "fix" per se, but one of the reasons I still use
> CouchDB 1.x is the change log. I have a homemade local syncing library for
> Livecode that I use that is heavily dependent on the old _changes api. I've
> been working on changing it for 2.x, but it involves having to add my own
> version of the change log to documents as they are being written)
>
> I understand why it was changed, but it would be great if there were a
> similar system available in 2.x
This is a great point!
It is regrettable, that 1.x had undefined behaviour that we had to give up
for 2.x, that folks relied on early on. It is the main one of the very few API
design mistakes we’ve made (IMHO), but there is no way to add 1.x behaviour to
2.x (although q=1 and n=1 will get you close).
Best
Jan
—
>
> On Thu, Jul 5, 2018 at 3:10 AM Johs Ensby <jo...@b2w.com> wrote:
>
>> This thread reach out to CouchDB 1.x users to generate a list of
>> "must-fix" issues that is preventing users to upgrade to the latest
>> version of CouchDB.
>>
>> It is in response to Joan's comment below regarding the
>> non-technical proposal to make a project decision to terminate
>> official Apache support for CouchDB 1.x.
>>
>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>> too would like to see pull requests for those. Once again, your help is
>>> most welcome in this - both in identifying a definitive list of those
>>> must-fix issues, as well as code towards fixing them. If you'd like
>>> to help with this important work, please start a new thread.
>>
>>
>>
>> Mine is CouchDB as a proxy.
>> The feature described here is not working in 2.1.1
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>
>> Johs
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Call for "Must-fix" issues
Posted by Jan Lehnardt <ja...@apache.org>.
> On 5. Jul 2018, at 13:54, Mad, Pink and Dangerous to Know <pi...@mad.pink> wrote:
>
> This isn't really a "fix" per se, but one of the reasons I still use
> CouchDB 1.x is the change log. I have a homemade local syncing library for
> Livecode that I use that is heavily dependent on the old _changes api. I've
> been working on changing it for 2.x, but it involves having to add my own
> version of the change log to documents as they are being written)
>
> I understand why it was changed, but it would be great if there were a
> similar system available in 2.x
This is a great point!
It is regrettable, that 1.x had undefined behaviour that we had to give up
for 2.x, that folks relied on early on. It is the main one of the very few API
design mistakes we’ve made (IMHO), but there is no way to add 1.x behaviour to
2.x (although q=1 and n=1 will get you close).
Best
Jan
—
>
> On Thu, Jul 5, 2018 at 3:10 AM Johs Ensby <jo...@b2w.com> wrote:
>
>> This thread reach out to CouchDB 1.x users to generate a list of
>> "must-fix" issues that is preventing users to upgrade to the latest
>> version of CouchDB.
>>
>> It is in response to Joan's comment below regarding the
>> non-technical proposal to make a project decision to terminate
>> official Apache support for CouchDB 1.x.
>>
>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>> too would like to see pull requests for those. Once again, your help is
>>> most welcome in this - both in identifying a definitive list of those
>>> must-fix issues, as well as code towards fixing them. If you'd like
>>> to help with this important work, please start a new thread.
>>
>>
>>
>> Mine is CouchDB as a proxy.
>> The feature described here is not working in 2.1.1
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>
>> Johs
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Call for "Must-fix" issues
Posted by "Mad, Pink and Dangerous to Know" <pi...@mad.pink>.
This isn't really a "fix" per se, but one of the reasons I still use
CouchDB 1.x is the change log. I have a homemade local syncing library for
Livecode that I use that is heavily dependent on the old _changes api. I've
been working on changing it for 2.x, but it involves having to add my own
version of the change log to documents as they are being written)
I understand why it was changed, but it would be great if there were a
similar system available in 2.x
On Thu, Jul 5, 2018 at 3:10 AM Johs Ensby <jo...@b2w.com> wrote:
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
> > On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >
> > As for things in 2.x that are "must fix" before people can upgrade, I
> > too would like to see pull requests for those. Once again, your help is
> > most welcome in this - both in identifying a definitive list of those
> > must-fix issues, as well as code towards fixing them. If you'd like
> > to help with this important work, please start a new thread.
>
>
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
>
Re: Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
Hi Harald,
how about starting a new thread on the topic, incuding dev@ and users@?
Compared to the https://db-engines.com/en/ranking_trend/system/CouchDB (auto collected web data)
the review service you linked to have a massive amount of reviews from MongoDB people.
Your question could motivate CouchDB users to summit reviews to g2crowd, and give detailed data in addition to the 44 people that did so already,
Johs:)
> On 5 Jul 2018, at 13:13, Harald Kisch <ha...@gmail.com> wrote:
>
> Previously I got a lot of recognition by using CouchDB 1.x
> Now I would be interested in the reasons why people prefer Mongo, Cassandra, Redis, HBase,..
> Is it the Quality of support only?
> https://www.g2crowd.com/categories/document-databases#highest_rated <https://www.g2crowd.com/categories/document-databases#highest_rated>
>
> harald
>
>> Am 05.07.2018 um 12:57 schrieb ermouth <er...@gmail.com>:
>>
>>> This is rather inaccurate
>>> A regrettable regression,
>>> but only a config issue
>>
>> Well enough to block upgrade. Anyway, as we see now those non-technical
>> issues of different nature improve the number of requests for paid support.
>> I wouldn’t account this fact as popularity, as Joan did, however hope it at
>> least sweetens regrets.
>>
>> ermouth
>
Re: Call for "Must-fix" issues
Posted by Harald Kisch <ha...@gmail.com>.
Previously I got a lot of recognition by using CouchDB 1.x
Now I would be interested in the reasons why people prefer Mongo, Cassandra, Redis, HBase,..
Is it the Quality of support only?
https://www.g2crowd.com/categories/document-databases#highest_rated <https://www.g2crowd.com/categories/document-databases#highest_rated>
harald
> Am 05.07.2018 um 12:57 schrieb ermouth <er...@gmail.com>:
>
>> This is rather inaccurate
>> A regrettable regression,
>> but only a config issue
>
> Well enough to block upgrade. Anyway, as we see now those non-technical
> issues of different nature improve the number of requests for paid support.
> I wouldn’t account this fact as popularity, as Joan did, however hope it at
> least sweetens regrets.
>
> ermouth
Re: Call for "Must-fix" issues
Posted by ermouth <er...@gmail.com>.
> This is rather inaccurate
> A regrettable regression,
> but only a config issue
Well enough to block upgrade. Anyway, as we see now those non-technical
issues of different nature improve the number of requests for paid support.
I wouldn’t account this fact as popularity, as Joan did, however hope it at
least sweetens regrets.
ermouth
Re: Call for "Must-fix" issues
Posted by Jan Lehnardt <ja...@apache.org>.
> On 5. Jul 2018, at 11:32, ermouth <er...@gmail.com> wrote:
>
>> convenience of one file on disk per database is gone, but is there
> anything else
>
> There were serious issues with single node shards (or whatever those pieces
> were) during upgrade from 2.1.0 to 2.1.1. I read only brief report, but
> remember it completely broken tests in some bizzare way, like inability to
> save docs with particular _id ranges.
This is rather inaccurate. The issue was a change of vm.args -name, that
made existing shards unreadable. A regrettable regression, but only a config
issue, that is a one line change to fix.
There was no technical issue here.
>
>> could you unveil this secret, please?
>
> There’s nothing secret here, theoretically you have to insert two oneliners
> into chttpd_auth and then rebuild. Obvious task for end user )
>
> -export([proxy_authentication_handler/1]).
> and
> proxy_authentication_handler(Req) ->
> couch_httpd_auth:proxy_authentication_handler(Req, chttpd_auth_cache).
>
> But as I can recollect it also finally broke things in some bizzare way.
>
>
> ermouth
>
> 2018-07-05 11:59 GMT+03:00 Johs Ensby <jo...@b2w.com>:
>
>>>>
>>>> Proxy authorization which is also in docs, but absent in 2.x.
>>>
>>> it is not absent, just not exposed by default. You can configure to
>> enable it (it’s just not documented ;)
>>
>> Hi Jan,
>> could you unveil this secret, please?
>> johs
>>
>>
>>
>>> On 5 Jul 2018, at 10:53, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>
>>>
>>>> On 5. Jul 2018, at 10:20, ermouth <er...@gmail.com> wrote:
>>>>
>>>> Proxy authorization which is also in docs, but absent in 2.x.
>>>
>>> it is not absent, just not exposed by default. You can configure to
>> enable it (it’s just not documented ;)
>>>
>>>> Single-node install without shards.
>>>
>>> Both the /_setup_cluster endpoint and the Mac binaries already set q=1 &
>> n = 1 on setup. Everyone else can configure it.
>>>
>>> Best
>>> Jan
>>> —
>>>
>>>>
>>>> ermouth
>>>>
>>>> 2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
>>>>
>>>>> This thread reach out to CouchDB 1.x users to generate a list of
>>>>> "must-fix" issues that is preventing users to upgrade to the latest
>>>>> version of CouchDB.
>>>>>
>>>>> It is in response to Joan's comment below regarding the
>>>>> non-technical proposal to make a project decision to terminate
>>>>> official Apache support for CouchDB 1.x.
>>>>>
>>>>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>>>>
>>>>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>>>>> too would like to see pull requests for those. Once again, your help
>> is
>>>>>> most welcome in this - both in identifying a definitive list of those
>>>>>> must-fix issues, as well as code towards fixing them. If you'd like
>>>>>> to help with this important work, please start a new thread.
>>>>>
>>>>>
>>>>>
>>>>> Mine is CouchDB as a proxy.
>>>>> The feature described here is not working in 2.1.1
>>>>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>>>>
>>>>> Johs
>>>>>
>>>
>>> --
>>> Professional Support for Apache CouchDB:
>>> https://neighbourhood.ie/couchdb-support/
>>>
>>
>> ………………………………………
>> 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
>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Call for "Must-fix" issues
Posted by ermouth <er...@gmail.com>.
> convenience of one file on disk per database is gone, but is there
anything else
There were serious issues with single node shards (or whatever those pieces
were) during upgrade from 2.1.0 to 2.1.1. I read only brief report, but
remember it completely broken tests in some bizzare way, like inability to
save docs with particular _id ranges.
> could you unveil this secret, please?
There’s nothing secret here, theoretically you have to insert two oneliners
into chttpd_auth and then rebuild. Obvious task for end user )
-export([proxy_authentication_handler/1]).
and
proxy_authentication_handler(Req) ->
couch_httpd_auth:proxy_authentication_handler(Req, chttpd_auth_cache).
But as I can recollect it also finally broke things in some bizzare way.
ermouth
2018-07-05 11:59 GMT+03:00 Johs Ensby <jo...@b2w.com>:
> >>
> >> Proxy authorization which is also in docs, but absent in 2.x.
> >
> > it is not absent, just not exposed by default. You can configure to
> enable it (it’s just not documented ;)
>
> Hi Jan,
> could you unveil this secret, please?
> johs
>
>
>
> > On 5 Jul 2018, at 10:53, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >
> >
> >> On 5. Jul 2018, at 10:20, ermouth <er...@gmail.com> wrote:
> >>
> >> Proxy authorization which is also in docs, but absent in 2.x.
> >
> > it is not absent, just not exposed by default. You can configure to
> enable it (it’s just not documented ;)
> >
> >> Single-node install without shards.
> >
> > Both the /_setup_cluster endpoint and the Mac binaries already set q=1 &
> n = 1 on setup. Everyone else can configure it.
> >
> > Best
> > Jan
> > —
> >
> >>
> >> ermouth
> >>
> >> 2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
> >>
> >>> This thread reach out to CouchDB 1.x users to generate a list of
> >>> "must-fix" issues that is preventing users to upgrade to the latest
> >>> version of CouchDB.
> >>>
> >>> It is in response to Joan's comment below regarding the
> >>> non-technical proposal to make a project decision to terminate
> >>> official Apache support for CouchDB 1.x.
> >>>
> >>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >>>>
> >>>> As for things in 2.x that are "must fix" before people can upgrade, I
> >>>> too would like to see pull requests for those. Once again, your help
> is
> >>>> most welcome in this - both in identifying a definitive list of those
> >>>> must-fix issues, as well as code towards fixing them. If you'd like
> >>>> to help with this important work, please start a new thread.
> >>>
> >>>
> >>>
> >>> Mine is CouchDB as a proxy.
> >>> The feature described here is not working in 2.1.1
> >>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
> >>>
> >>> Johs
> >>>
> >
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> >
>
> ………………………………………
> 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: Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
>>
>> Proxy authorization which is also in docs, but absent in 2.x.
>
> it is not absent, just not exposed by default. You can configure to enable it (it’s just not documented ;)
Hi Jan,
could you unveil this secret, please?
johs
> On 5 Jul 2018, at 10:53, Jan Lehnardt <ja...@apache.org> wrote:
>
>
>
>> On 5. Jul 2018, at 10:20, ermouth <er...@gmail.com> wrote:
>>
>> Proxy authorization which is also in docs, but absent in 2.x.
>
> it is not absent, just not exposed by default. You can configure to enable it (it’s just not documented ;)
>
>> Single-node install without shards.
>
> Both the /_setup_cluster endpoint and the Mac binaries already set q=1 & n = 1 on setup. Everyone else can configure it.
>
> Best
> Jan
> —
>
>>
>> ermouth
>>
>> 2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
>>
>>> This thread reach out to CouchDB 1.x users to generate a list of
>>> "must-fix" issues that is preventing users to upgrade to the latest
>>> version of CouchDB.
>>>
>>> It is in response to Joan's comment below regarding the
>>> non-technical proposal to make a project decision to terminate
>>> official Apache support for CouchDB 1.x.
>>>
>>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>>
>>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>>> too would like to see pull requests for those. Once again, your help is
>>>> most welcome in this - both in identifying a definitive list of those
>>>> must-fix issues, as well as code towards fixing them. If you'd like
>>>> to help with this important work, please start a new thread.
>>>
>>>
>>>
>>> Mine is CouchDB as a proxy.
>>> The feature described here is not working in 2.1.1
>>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>>
>>> Johs
>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
………………………………………
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: Call for "Must-fix" issues
Posted by Jan Lehnardt <ja...@apache.org>.
> On 5. Jul 2018, at 10:20, ermouth <er...@gmail.com> wrote:
>
> Proxy authorization which is also in docs, but absent in 2.x.
it is not absent, just not exposed by default. You can configure to enable it (it’s just not documented ;)
> Single-node install without shards.
Both the /_setup_cluster endpoint and the Mac binaries already set q=1 & n = 1 on setup. Everyone else can configure it.
Best
Jan
—
>
> ermouth
>
> 2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
>
>> This thread reach out to CouchDB 1.x users to generate a list of
>> "must-fix" issues that is preventing users to upgrade to the latest
>> version of CouchDB.
>>
>> It is in response to Joan's comment below regarding the
>> non-technical proposal to make a project decision to terminate
>> official Apache support for CouchDB 1.x.
>>
>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>> too would like to see pull requests for those. Once again, your help is
>>> most welcome in this - both in identifying a definitive list of those
>>> must-fix issues, as well as code towards fixing them. If you'd like
>>> to help with this important work, please start a new thread.
>>
>>
>>
>> Mine is CouchDB as a proxy.
>> The feature described here is not working in 2.1.1
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>
>> Johs
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
Thanks,
what is the issue related to Single-node install without shards?
(I noticed that the convenience of one file on disk per database is gone, but is there anything else?)
Johs
> On 5 Jul 2018, at 10:50, ermouth <er...@gmail.com> wrote:
>
> Single-node install without shards.
>
> ermouth
>
> 2018-07-05 11:20 GMT+03:00 ermouth <er...@gmail.com>:
>
>> Proxy authorization which is also in docs, but absent in 2.x.
>>
>> ermouth
>>
>> 2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
>>
>>> This thread reach out to CouchDB 1.x users to generate a list of
>>> "must-fix" issues that is preventing users to upgrade to the latest
>>> version of CouchDB.
>>>
>>> It is in response to Joan's comment below regarding the
>>> non-technical proposal to make a project decision to terminate
>>> official Apache support for CouchDB 1.x.
>>>
>>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>>
>>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>>> too would like to see pull requests for those. Once again, your help is
>>>> most welcome in this - both in identifying a definitive list of those
>>>> must-fix issues, as well as code towards fixing them. If you'd like
>>>> to help with this important work, please start a new thread.
>>>
>>>
>>>
>>> Mine is CouchDB as a proxy.
>>> The feature described here is not working in 2.1.1
>>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>>
>>> Johs
>>>
>>
>>
………………………………………
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: Call for "Must-fix" issues
Posted by ermouth <er...@gmail.com>.
Single-node install without shards.
ermouth
2018-07-05 11:20 GMT+03:00 ermouth <er...@gmail.com>:
> Proxy authorization which is also in docs, but absent in 2.x.
>
> ermouth
>
> 2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
>
>> This thread reach out to CouchDB 1.x users to generate a list of
>> "must-fix" issues that is preventing users to upgrade to the latest
>> version of CouchDB.
>>
>> It is in response to Joan's comment below regarding the
>> non-technical proposal to make a project decision to terminate
>> official Apache support for CouchDB 1.x.
>>
>> > On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>> >
>> > As for things in 2.x that are "must fix" before people can upgrade, I
>> > too would like to see pull requests for those. Once again, your help is
>> > most welcome in this - both in identifying a definitive list of those
>> > must-fix issues, as well as code towards fixing them. If you'd like
>> > to help with this important work, please start a new thread.
>>
>>
>>
>> Mine is CouchDB as a proxy.
>> The feature described here is not working in 2.1.1
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>
>> Johs
>>
>
>
Re: Call for "Must-fix" issues
Posted by ermouth <er...@gmail.com>.
Proxy authorization which is also in docs, but absent in 2.x.
ermouth
2018-07-05 10:10 GMT+03:00 Johs Ensby <jo...@b2w.com>:
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
> > On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >
> > As for things in 2.x that are "must fix" before people can upgrade, I
> > too would like to see pull requests for those. Once again, your help is
> > most welcome in this - both in identifying a definitive list of those
> > must-fix issues, as well as code towards fixing them. If you'd like
> > to help with this important work, please start a new thread.
>
>
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
>
Re: Call for "Must-fix" issues
Posted by "Mad, Pink and Dangerous to Know" <pi...@mad.pink>.
This isn't really a "fix" per se, but one of the reasons I still use
CouchDB 1.x is the change log. I have a homemade local syncing library for
Livecode that I use that is heavily dependent on the old _changes api. I've
been working on changing it for 2.x, but it involves having to add my own
version of the change log to documents as they are being written)
I understand why it was changed, but it would be great if there were a
similar system available in 2.x
On Thu, Jul 5, 2018 at 3:10 AM Johs Ensby <jo...@b2w.com> wrote:
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
> > On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >
> > As for things in 2.x that are "must fix" before people can upgrade, I
> > too would like to see pull requests for those. Once again, your help is
> > most welcome in this - both in identifying a definitive list of those
> > must-fix issues, as well as code towards fixing them. If you'd like
> > to help with this important work, please start a new thread.
>
>
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
>
Re: Call for "Must-fix" issues
Posted by Aurélien Bénel <au...@utt.fr>.
Hi Joan, hi Johs,
>> As for things in 2.x that are « must fix" before people can upgrade, I too would like to see pull requests for those. Once again, your help is most welcome in this - both in identifying a definitive list of those must-fix issues, as well as code towards fixing them. If you’d like to help with this important work, please start a new thread.
Mine is « Views ETags » for HTTP caching (COUCHDB-2859).
https://github.com/apache/couchdb/pull/1237
Regards,
Aurélien
Re: Call for "Must-fix" issues
Posted by Aurélien Bénel <au...@utt.fr>.
Hi Joan, hi Johs,
>> As for things in 2.x that are « must fix" before people can upgrade, I too would like to see pull requests for those. Once again, your help is most welcome in this - both in identifying a definitive list of those must-fix issues, as well as code towards fixing them. If you’d like to help with this important work, please start a new thread.
Mine is « Views ETags » for HTTP caching (COUCHDB-2859).
https://github.com/apache/couchdb/pull/1237
Regards,
Aurélien
Re: Call for "Must-fix" issues
Posted by ermouth <er...@gmail.com>.
I’m sorry to say, but:
— Fauxton is unable to show doc attachments list in any modern browser on
http connection
— Fauxton is still unable to make “Back” button working in _config section
— Fauxton doesn’t work on ~20% of browsers, polyfills for missing browser
features is still an unknown term for Fauxton
— Fauxton is still unable to validate at least JSON syntax on typing, I’m
not saying about Mango syntax
— Fauxton is still all about making as much UI noise as possible,
sacrificing data density
I discovered all this in first 2 minutes after install – just to check have
anything changed. You said tables?
I’m sorry to say, but tables is the least problem. Anyway, Fauxton is
absolutely on par with CouchDB 2 in terms of product quality. An you
enforce people to migrate on _this_? Are you kidding?
And, to prevent known spells: sorry, no bug reports and no pull requests,
all above problems were already reported.
ermouth
Re: Call for "Must-fix" issues
Posted by Garren Smith <ga...@apache.org>.
Hi Kai,
Fauxton now supports a table view which allows you to see many documents at
once as well as choosing which key values to see in the table. Its been out
for a while so I'm sure its in the current release but will definitely be
in the next.
Cheers
Garren
On Thu, Jul 5, 2018 at 9:32 AM, Kai Griffin <ka...@resourceandrevenue.com>
wrote:
> As developers who spend a lot of time in the CouchDB web interface, we
> have held back moving to CouchDB 2.x only because of the change from Futon
> to Fauxton. We feel that Fauxton simply does not meet the needs of
> developers as well as Futon did. It seems to be targeted more at non-devs:
> it’s very friendly-looking, modern & pretty, but is biased towards
> prettifying document JSON, at the expense of being able to scan through
> many unformatted documents, which Futon does by default.
>
> So, mainly comes down to the inability to properly see the contents of
> documents without opening up documents individually. We like to see the
> whole, unformatted document when viewing a list of documents (or, in the
> case of looking at a View, then whatever the map script outputs, but in an
> unformatted form, not prettified like Fauxton). Futon is more compact &
> developer friendly, even if to a non-dev, such views might look like a
> jumble of unformatted text. At very least, some kind of “classic mode”
> switch would be greatly welcomed, at least by us :-)
>
> Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and
> the issue I brought up above might well have been addressed by someone in
> the meantime, so apologies if I’m dredging up old/non-relevant stuff (in
> which case we’ll happily jump onto 2.x!)
>
>
> On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it)
> wrote:
>
> Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
>
> On 2018-07-05 09:10, Johs Ensby wrote:
>
> > This thread reach out to CouchDB 1.x users to generate a list of
> > "must-fix" issues that is preventing users to upgrade to the latest
> > version of CouchDB.
> >
> > It is in response to Joan's comment below regarding the
> > non-technical proposal to make a project decision to terminate
> > official Apache support for CouchDB 1.x.
> >
> >> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >>
> >> As for things in 2.x that are "must fix" before people can upgrade, I
> >> too would like to see pull requests for those. Once again, your help
> is
> >> most welcome in this - both in identifying a definitive list of those
> >> must-fix issues, as well as code towards fixing them. If you'd like
> >> to help with this important work, please start a new thread.
> >
> > Mine is CouchDB as a proxy.
> > The feature described here is not working in 2.1.1
> > http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
> >
> > Johs
>
Re: Call for "Must-fix" issues
Posted by Garren Smith <ga...@apache.org>.
Hi Kai,
Fauxton now supports a table view which allows you to see many documents at
once as well as choosing which key values to see in the table. Its been out
for a while so I'm sure its in the current release but will definitely be
in the next.
Cheers
Garren
On Thu, Jul 5, 2018 at 9:32 AM, Kai Griffin <ka...@resourceandrevenue.com>
wrote:
> As developers who spend a lot of time in the CouchDB web interface, we
> have held back moving to CouchDB 2.x only because of the change from Futon
> to Fauxton. We feel that Fauxton simply does not meet the needs of
> developers as well as Futon did. It seems to be targeted more at non-devs:
> it’s very friendly-looking, modern & pretty, but is biased towards
> prettifying document JSON, at the expense of being able to scan through
> many unformatted documents, which Futon does by default.
>
> So, mainly comes down to the inability to properly see the contents of
> documents without opening up documents individually. We like to see the
> whole, unformatted document when viewing a list of documents (or, in the
> case of looking at a View, then whatever the map script outputs, but in an
> unformatted form, not prettified like Fauxton). Futon is more compact &
> developer friendly, even if to a non-dev, such views might look like a
> jumble of unformatted text. At very least, some kind of “classic mode”
> switch would be greatly welcomed, at least by us :-)
>
> Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and
> the issue I brought up above might well have been addressed by someone in
> the meantime, so apologies if I’m dredging up old/non-relevant stuff (in
> which case we’ll happily jump onto 2.x!)
>
>
> On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it)
> wrote:
>
> Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
>
> On 2018-07-05 09:10, Johs Ensby wrote:
>
> > This thread reach out to CouchDB 1.x users to generate a list of
> > "must-fix" issues that is preventing users to upgrade to the latest
> > version of CouchDB.
> >
> > It is in response to Joan's comment below regarding the
> > non-technical proposal to make a project decision to terminate
> > official Apache support for CouchDB 1.x.
> >
> >> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >>
> >> As for things in 2.x that are "must fix" before people can upgrade, I
> >> too would like to see pull requests for those. Once again, your help
> is
> >> most welcome in this - both in identifying a definitive list of those
> >> must-fix issues, as well as code towards fixing them. If you'd like
> >> to help with this important work, please start a new thread.
> >
> > Mine is CouchDB as a proxy.
> > The feature described here is not working in 2.1.1
> > http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
> >
> > Johs
>
Re: Call for "Must-fix" issues
Posted by Garren Smith <ga...@apache.org>.
Hi Kai,
Fauxton now supports a table view which allows you to see many documents at
once as well as choosing which key values to see in the table. Its been out
for a while so I'm sure its in the current release but will definitely be
in the next.
Cheers
Garren
On Thu, Jul 5, 2018 at 9:32 AM, Kai Griffin <ka...@resourceandrevenue.com>
wrote:
> As developers who spend a lot of time in the CouchDB web interface, we
> have held back moving to CouchDB 2.x only because of the change from Futon
> to Fauxton. We feel that Fauxton simply does not meet the needs of
> developers as well as Futon did. It seems to be targeted more at non-devs:
> it’s very friendly-looking, modern & pretty, but is biased towards
> prettifying document JSON, at the expense of being able to scan through
> many unformatted documents, which Futon does by default.
>
> So, mainly comes down to the inability to properly see the contents of
> documents without opening up documents individually. We like to see the
> whole, unformatted document when viewing a list of documents (or, in the
> case of looking at a View, then whatever the map script outputs, but in an
> unformatted form, not prettified like Fauxton). Futon is more compact &
> developer friendly, even if to a non-dev, such views might look like a
> jumble of unformatted text. At very least, some kind of “classic mode”
> switch would be greatly welcomed, at least by us :-)
>
> Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and
> the issue I brought up above might well have been addressed by someone in
> the meantime, so apologies if I’m dredging up old/non-relevant stuff (in
> which case we’ll happily jump onto 2.x!)
>
>
> On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it)
> wrote:
>
> Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
>
> On 2018-07-05 09:10, Johs Ensby wrote:
>
> > This thread reach out to CouchDB 1.x users to generate a list of
> > "must-fix" issues that is preventing users to upgrade to the latest
> > version of CouchDB.
> >
> > It is in response to Joan's comment below regarding the
> > non-technical proposal to make a project decision to terminate
> > official Apache support for CouchDB 1.x.
> >
> >> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >>
> >> As for things in 2.x that are "must fix" before people can upgrade, I
> >> too would like to see pull requests for those. Once again, your help
> is
> >> most welcome in this - both in identifying a definitive list of those
> >> must-fix issues, as well as code towards fixing them. If you'd like
> >> to help with this important work, please start a new thread.
> >
> > Mine is CouchDB as a proxy.
> > The feature described here is not working in 2.1.1
> > http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
> >
> > Johs
>
Re: Call for "Must-fix" issues
Posted by Martin Rudolph <m....@email.de>.
We are currently working on switching all our projects to CouchDB 2.x and facing many issues and problems that we have to fix/change on our side, but this is taking a lot of time. E.g.
In one project we are using OAuth 1.0 for authentication, that was pretty good integrated, but it is not available anymore. We know about the reasons for removing this feature, but to switch this on our project we will need time.
In one project we are using Geocouch, I’m not sure if this is still working for CouchDB 2.x, perhaps someone can point here some information about this?
We have faced some issues with proxy configuration for replications, see https://github.com/apache/couchdb/issues/1080
There seems to be a change in the Content-Security-Policy, which does not allow to evaluate code in the validate_doc_update.js anymore, this was also a blocker for us. But we where able to fix this.
And then there is Fauxton. When it first was introduced I liked it pretty much and thought hey a new UI, finally. But now I’m not happy with it and missing some major functionalities:
1. Compact a Database
2. Adding just a field to a document. I know I can do this in JSON as well, but in many cases it was just easier and quicker, by using this functionality.
3. By the way, where is the fields view? It was pretty good to get an overview about a big document.
4. Why are the _users and _replicator databases not shown in Fauxton?
Please do not see anything as criticism, CouchDB 2.x and Fauxton are great and the step in the right direction. We want and will switch to the new version, but there are several issues that needs to be fixed, on our side!
Regards
Martin
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>
>> As for things in 2.x that are "must fix" before people can upgrade, I
>> too would like to see pull requests for those. Once again, your help is
>> most welcome in this - both in identifying a definitive list of those
>> must-fix issues, as well as code towards fixing them. If you'd like
>> to help with this important work, please start a new thread.
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
Re: Call for "Must-fix" issues
Posted by Jan Lehnardt <ja...@apache.org>.
Heya Eli,
2.2.0 is imminent, two minor issues outstanding:
https://github.com/apache/couchdb/milestone/3
This took longer than it should have for various reasons, but we should be in shape to do more regular releases going forward.
Best
Jan
—
> On 16. Jul 2018, at 20:24, Eli Stevens (Gmail) <wi...@gmail.com> wrote:
>
> I was travelling, so missed this thread originally.
>
> My[1] organization is currently not using CouchDB 2.0 in production due to
> a series of regressions in all 2.x releases that have meant that 1.6.1 was
> the most stable for us. All of the currently-known issues are fixed on
> master, and we're currently evaluating a nightly build to verify. It would
> be really nice if there was a 2.2 release so that we could get those fixes
> in the form of a formal build (note that we sponsored some of the work on
> those fixes, hoping that a release would get turned around relatively
> quickly afterwards).
>
> A regular release cadence would be really nice.
>
> Cheers,
> Eli
>
> [1] - I should note that I've quit that company, so I'm no longer formally
> associated.
>
> On Fri, Jul 6, 2018 at 11:04 AM Joan Touzet <wo...@apache.org> wrote:
>
>> I agree that this semantic change is an unfortunate problem in the 1.x to
>> 2.x upgrade path and needs to be addressed.
>>
>> It is irresponsible to tell users that a valid workaround is to use an
>> insecure, untested, not-clustered and not-fully-functional port as the
>> primary access to CouchDB. The consequences are worse than the workaround.
>>
>> -Joan
>>
>> ----- Original Message -----
>>
>>> From: "Igor Ievsiukov" <ig...@gmail.com>
>>> To: wohali@apache.org
>>> Cc: user@couchdb.apache.org
>>> Sent: Friday, July 6, 2018 12:15:26 PM
>>> Subject: Re: Call for "Must-fix" issues
>>
>>> Hi Joan,
>>
>>> Thank you for additional explanations.
>>
>>> I myself know this rule very well, but imagine a scenario of a
>>> sysadmin in some company, not aware of this nuance, upgrading
>>> couchdb1x => 2x on their internal app that still uses the old repl
>>> doc seantics – the side-effect might not be visible at first, but
>>> the consequences will be very nasty and a very angry user in the
>>> end.
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Call for "Must-fix" issues
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
I was travelling, so missed this thread originally.
My[1] organization is currently not using CouchDB 2.0 in production due to
a series of regressions in all 2.x releases that have meant that 1.6.1 was
the most stable for us. All of the currently-known issues are fixed on
master, and we're currently evaluating a nightly build to verify. It would
be really nice if there was a 2.2 release so that we could get those fixes
in the form of a formal build (note that we sponsored some of the work on
those fixes, hoping that a release would get turned around relatively
quickly afterwards).
A regular release cadence would be really nice.
Cheers,
Eli
[1] - I should note that I've quit that company, so I'm no longer formally
associated.
On Fri, Jul 6, 2018 at 11:04 AM Joan Touzet <wo...@apache.org> wrote:
> I agree that this semantic change is an unfortunate problem in the 1.x to
> 2.x upgrade path and needs to be addressed.
>
> It is irresponsible to tell users that a valid workaround is to use an
> insecure, untested, not-clustered and not-fully-functional port as the
> primary access to CouchDB. The consequences are worse than the workaround.
>
> -Joan
>
> ----- Original Message -----
>
> > From: "Igor Ievsiukov" <ig...@gmail.com>
> > To: wohali@apache.org
> > Cc: user@couchdb.apache.org
> > Sent: Friday, July 6, 2018 12:15:26 PM
> > Subject: Re: Call for "Must-fix" issues
>
> > Hi Joan,
>
> > Thank you for additional explanations.
>
> > I myself know this rule very well, but imagine a scenario of a
> > sysadmin in some company, not aware of this nuance, upgrading
> > couchdb1x => 2x on their internal app that still uses the old repl
> > doc seantics – the side-effect might not be visible at first, but
> > the consequences will be very nasty and a very angry user in the
> > end.
>
Re: Call for "Must-fix" issues
Posted by Joan Touzet <wo...@apache.org>.
I agree that this semantic change is an unfortunate problem in the 1.x to 2.x upgrade path and needs to be addressed.
It is irresponsible to tell users that a valid workaround is to use an insecure, untested, not-clustered and not-fully-functional port as the primary access to CouchDB. The consequences are worse than the workaround.
-Joan
----- Original Message -----
> From: "Igor Ievsiukov" <ig...@gmail.com>
> To: wohali@apache.org
> Cc: user@couchdb.apache.org
> Sent: Friday, July 6, 2018 12:15:26 PM
> Subject: Re: Call for "Must-fix" issues
> Hi Joan,
> Thank you for additional explanations.
> I myself know this rule very well, but imagine a scenario of a
> sysadmin in some company, not aware of this nuance, upgrading
> couchdb1x => 2x on their internal app that still uses the old repl
> doc seantics – the side-effect might not be visible at first, but
> the consequences will be very nasty and a very angry user in the
> end.
Re: Call for "Must-fix" issues
Posted by Igor Ievsiukov <ig...@gmail.com>.
Hi Joan,
Thank you for additional explanations.
I myself know this rule very well, but imagine a scenario of a sysadmin in
some company, not aware of this nuance, upgrading couchdb1x => 2x on their
internal app that still uses the old repl doc seantics – the side-effect
might not be visible at first, but the consequences will be very nasty and
a very angry user in the end.
- Igor
Le ven. 6 juil. 2018 à 18:01, Joan Touzet <wo...@apache.org> a écrit :
> HI Igor,
>
> Just to call out: *Don't use the node-local port(5986) for any
> replication other than migrating 1.x databases to 2.x* (as performed by
> couchup).
>
> Also, do not use the node-local port for any other operations unless the
> documentation explicitly directs you to do so.
>
> Port 5986 is deprecated for all other purposes in 2.x, and will be removed
> in 3.x.
>
> -Joan
>
> ------------------------------
>
> *From: *"Igor Ievsiukov" <ig...@gmail.com>
> *To: *user@couchdb.apache.org
> *Cc: *wohali@apache.org
> *Sent: *Friday, July 6, 2018 11:51:04 AM
> *Subject: *Re: Call for "Must-fix" issues
>
> Hi everyone,
>
> +1 to view E-Tags
>
> my 2c: replication doc semantics compatibility
>
> couchdb1.x
> {
> "source": "db1",
> "target": "http://user:pass@localhost/db2"
> }
> ^ both db name and url supported
>
> couchdb2.x
> {
> "source": "http://user:pass@localhost/db1",
> "target": "http://user:pass@localhost/db2"
> }
> ^ only url is supported; db name uses node-local port
>
> while not the biggest problem, still requires application refactoring
> which is not always possible and could be a blocking point for some.
>
> - Igor
>
> Le ven. 6 juil. 2018 à 14:44, Johs Ensby <jo...@b2w.com> a écrit :
>
>> Hi,
>> Here's a wrap-up of this from my side.
>> Johs
>>
>> #### UPGRADE-BLOCKING
>> ========================================================
>> Views ETags for HTTP caching
>> --------------------------------------------------------------------------------------------------
>>
>> (thanks to Aurélien)
>> (COUCHDB-2859)
>> https://github.com/apache/couchdb/pull/1237
>>
>> ========================================================
>> Proxy authorization
>> --------------------------------------------------------------------------------------------------
>>
>> (thanks to emouth)
>> -export([proxy_authentication_handler/1]) and
>> proxy_authentication_handler(Req) ->
>> couch_httpd_auth:proxy_authentication_handler(Req, chttpd_auth_cache).
>> In docs, but absent in 2.x.
>>
>> ========================================================
>> CouchDB as a proxy
>> --------------------------------------------------------------------------------------------------
>>
>> https://github.com/apache/couchdb/issues/1407
>> In docs, but absent in 2.1.1
>>
>> ========================================================
>> Fauxton
>> --------------------------------------------------------------------------------------------------
>>
>> (thanks to Kai)
>> Productivity/UX issues
>> As an slternative I recommend to https://github.com/ermouth/couch-photon
>>
>> PLATFORM-SPECIFC
>> ========================================================
>> Lack for a working FreeBSD port
>> --------------------------------------------------------------------------------------------------
>>
>> (thanks to Andrea)
>>
>>
>> #### ENHANCEMENT suggestions
>> ========================================================
>> Fauxton
>> --------------------------------------------------------------------------------------------------
>>
>> (thanks to David)
>> logged by Joan:
>> https://github.com/apache/couchdb-fauxton/issues/1099
>> https://github.com/apache/couchdb-fauxton/issues/1100
>>
>> --------------------------------------------------------------------------------------------------
>>
>>
>>
>> I left aside reports of 1.x behaviour not possible to add to 2.x (ref
>> Jans respons)
>>
>> > On 5 Jul 2018, at 17:46, Joan Touzet <wo...@apache.org> wrote:
>> >
>> >> On 2018-07-05 09:10, Johs Ensby wrote:
>> >>
>> >>> This thread reach out to CouchDB 1.x users to generate a list of
>> >>> "must-fix" issues that is preventing users to upgrade to the latest
>> >>> version of CouchDB.
>> >>>
>> >>> It is in response to Joan's comment below regarding the
>> >>> non-technical proposal to make a project decision to terminate
>> >>> official Apache support for CouchDB 1.x.
>> >>>
>> >>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>> >>>>
>> >>>> As for things in 2.x that are "must fix" before people can upgrade,
>> I
>> >>>> too would like to see pull requests for those. Once again, your help
>> is
>> >>>> most welcome in this - both in identifying a definitive list of
>> those
>> >>>> must-fix issues, as well as code towards fixing them. If you'd like
>> >>>> to help with this important work, please start a new thread.
>> >>>
>> >>> Mine is CouchDB as a proxy.
>> >>> The feature described here is not working in 2.1.1
>> >>>
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>> >>>
>> >>> Johs
>>
>>
>>
>
Re: Call for "Must-fix" issues
Posted by Joan Touzet <wo...@apache.org>.
HI Igor,
Just to call out: Don't use the node-local port(5986) for any replication other than migrating 1.x databases to 2.x (as performed by couchup).
Also, do not use the node-local port for any other operations unless the documentation explicitly directs you to do so.
Port 5986 is deprecated for all other purposes in 2.x, and will be removed in 3.x.
-Joan
----- Original Message -----
> From: "Igor Ievsiukov" <ig...@gmail.com>
> To: user@couchdb.apache.org
> Cc: wohali@apache.org
> Sent: Friday, July 6, 2018 11:51:04 AM
> Subject: Re: Call for "Must-fix" issues
> Hi everyone,
> +1 to view E-Tags
> my 2c: replication doc semantics compatibility
> couchdb1.x
> {
> "source": "db1",
> "target": "http://user:pass@localhost/db2"
> }
> ^ both db name and url supported
> couchdb2.x
> {
> "source": " http://user:pass@localhost/db1 ",
> "target": "http://user:pass@localhost/db2"
> } ^ only url is supported; db name uses node-local port
> while not the biggest problem, still requires application refactoring
> which is not always possible and could be a blocking point for some.
> - Igor
> Le ven. 6 juil. 2018 à 14:44, Johs Ensby < johs@b2w.com > a écrit :
> > Hi,
>
> > Here's a wrap-up of this from my side.
>
> > Johs
>
> > #### UPGRADE-BLOCKING
>
> > ========================================================
>
> > Views ETags for HTTP caching
>
> > --------------------------------------------------------------------------------------------------
>
> > (thanks to Aurélien)
>
> > (COUCHDB-2859)
>
> > https://github.com/apache/couchdb/pull/1237
>
> > ========================================================
>
> > Proxy authorization
>
> > --------------------------------------------------------------------------------------------------
>
> > (thanks to emouth)
>
> > -export([proxy_authentication_handler/1]) and
>
> > proxy_authentication_handler(Req) ->
>
> > couch_httpd_auth:proxy_authentication_handler(Req,
> > chttpd_auth_cache).
>
> > In docs, but absent in 2.x.
>
> > ========================================================
>
> > CouchDB as a proxy
>
> > --------------------------------------------------------------------------------------------------
>
> > https://github.com/apache/couchdb/issues/1407
>
> > In docs, but absent in 2.1.1
>
> > ========================================================
>
> > Fauxton
>
> > --------------------------------------------------------------------------------------------------
>
> > (thanks to Kai)
>
> > Productivity/UX issues
>
> > As an slternative I recommend to
> > https://github.com/ermouth/couch-photon
>
> > PLATFORM-SPECIFC
>
> > ========================================================
>
> > Lack for a working FreeBSD port
>
> > --------------------------------------------------------------------------------------------------
>
> > (thanks to Andrea)
>
> > #### ENHANCEMENT suggestions
>
> > ========================================================
>
> > Fauxton
>
> > --------------------------------------------------------------------------------------------------
>
> > (thanks to David)
>
> > logged by Joan:
>
> > https://github.com/apache/couchdb-fauxton/issues/1099
>
> > https://github.com/apache/couchdb-fauxton/issues/1100
>
> > --------------------------------------------------------------------------------------------------
>
> > I left aside reports of 1.x behaviour not possible to add to 2.x
> > (ref
> > Jans respons)
>
> > > On 5 Jul 2018, at 17:46, Joan Touzet < wohali@apache.org > wrote:
>
> > >
>
> > >> On 2018-07-05 09:10, Johs Ensby wrote:
>
> > >>
>
> > >>> This thread reach out to CouchDB 1.x users to generate a list
> > >>> of
>
> > >>> "must-fix" issues that is preventing users to upgrade to the
> > >>> latest
>
> > >>> version of CouchDB.
>
> > >>>
>
> > >>> It is in response to Joan's comment below regarding the
>
> > >>> non-technical proposal to make a project decision to terminate
>
> > >>> official Apache support for CouchDB 1.x.
>
> > >>>
>
> > >>>> On 5 Jul 2018, at 06:31, Joan Touzet < wohali@apache.org >
> > >>>> wrote:
>
> > >>>>
>
> > >>>> As for things in 2.x that are "must fix" before people can
> > >>>> upgrade, I
>
> > >>>> too would like to see pull requests for those. Once again,
> > >>>> your
> > >>>> help is
>
> > >>>> most welcome in this - both in identifying a definitive list
> > >>>> of
> > >>>> those
>
> > >>>> must-fix issues, as well as code towards fixing them. If you'd
> > >>>> like
>
> > >>>> to help with this important work, please start a new thread.
>
> > >>>
>
> > >>> Mine is CouchDB as a proxy.
>
> > >>> The feature described here is not working in 2.1.1
>
> > >>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> > >>>
>
> > >>> Johs
>
Re: Call for "Must-fix" issues
Posted by Igor Ievsiukov <ig...@gmail.com>.
Hi everyone,
+1 to view E-Tags
my 2c: replication doc semantics compatibility
couchdb1.x
{
"source": "db1",
"target": "http://user:pass@localhost/db2"
}
^ both db name and url supported
couchdb2.x
{
"source": "http://user:pass@localhost/db1",
"target": "http://user:pass@localhost/db2"
}
^ only url is supported; db name uses node-local port
while not the biggest problem, still requires application refactoring which
is not always possible and could be a blocking point for some.
- Igor
Le ven. 6 juil. 2018 à 14:44, Johs Ensby <jo...@b2w.com> a écrit :
> Hi,
> Here's a wrap-up of this from my side.
> Johs
>
> #### UPGRADE-BLOCKING
> ========================================================
> Views ETags for HTTP caching
> --------------------------------------------------------------------------------------------------
>
> (thanks to Aurélien)
> (COUCHDB-2859)
> https://github.com/apache/couchdb/pull/1237
>
> ========================================================
> Proxy authorization
> --------------------------------------------------------------------------------------------------
>
> (thanks to emouth)
> -export([proxy_authentication_handler/1]) and
> proxy_authentication_handler(Req) ->
> couch_httpd_auth:proxy_authentication_handler(Req, chttpd_auth_cache).
> In docs, but absent in 2.x.
>
> ========================================================
> CouchDB as a proxy
> --------------------------------------------------------------------------------------------------
>
> https://github.com/apache/couchdb/issues/1407
> In docs, but absent in 2.1.1
>
> ========================================================
> Fauxton
> --------------------------------------------------------------------------------------------------
>
> (thanks to Kai)
> Productivity/UX issues
> As an slternative I recommend to https://github.com/ermouth/couch-photon
>
> PLATFORM-SPECIFC
> ========================================================
> Lack for a working FreeBSD port
> --------------------------------------------------------------------------------------------------
>
> (thanks to Andrea)
>
>
> #### ENHANCEMENT suggestions
> ========================================================
> Fauxton
> --------------------------------------------------------------------------------------------------
>
> (thanks to David)
> logged by Joan:
> https://github.com/apache/couchdb-fauxton/issues/1099
> https://github.com/apache/couchdb-fauxton/issues/1100
>
> --------------------------------------------------------------------------------------------------
>
>
>
> I left aside reports of 1.x behaviour not possible to add to 2.x (ref Jans
> respons)
>
> > On 5 Jul 2018, at 17:46, Joan Touzet <wo...@apache.org> wrote:
> >
> >> On 2018-07-05 09:10, Johs Ensby wrote:
> >>
> >>> This thread reach out to CouchDB 1.x users to generate a list of
> >>> "must-fix" issues that is preventing users to upgrade to the latest
> >>> version of CouchDB.
> >>>
> >>> It is in response to Joan's comment below regarding the
> >>> non-technical proposal to make a project decision to terminate
> >>> official Apache support for CouchDB 1.x.
> >>>
> >>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
> >>>>
> >>>> As for things in 2.x that are "must fix" before people can upgrade,
> I
> >>>> too would like to see pull requests for those. Once again, your help
> is
> >>>> most welcome in this - both in identifying a definitive list of
> those
> >>>> must-fix issues, as well as code towards fixing them. If you'd like
> >>>> to help with this important work, please start a new thread.
> >>>
> >>> Mine is CouchDB as a proxy.
> >>> The feature described here is not working in 2.1.1
> >>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> >>>
> >>> Johs
>
>
>
Re: Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
Hi,
Here's a wrap-up of this from my side.
Johs
#### UPGRADE-BLOCKING
========================================================
Views ETags for HTTP caching
--------------------------------------------------------------------------------------------------
(thanks to Aurélien)
(COUCHDB-2859)
https://github.com/apache/couchdb/pull/1237
========================================================
Proxy authorization
--------------------------------------------------------------------------------------------------
(thanks to emouth)
-export([proxy_authentication_handler/1]) and
proxy_authentication_handler(Req) ->
couch_httpd_auth:proxy_authentication_handler(Req, chttpd_auth_cache).
In docs, but absent in 2.x.
========================================================
CouchDB as a proxy
--------------------------------------------------------------------------------------------------
https://github.com/apache/couchdb/issues/1407
In docs, but absent in 2.1.1
========================================================
Fauxton
--------------------------------------------------------------------------------------------------
(thanks to Kai)
Productivity/UX issues
As an slternative I recommend to https://github.com/ermouth/couch-photon
PLATFORM-SPECIFC
========================================================
Lack for a working FreeBSD port
--------------------------------------------------------------------------------------------------
(thanks to Andrea)
#### ENHANCEMENT suggestions
========================================================
Fauxton
--------------------------------------------------------------------------------------------------
(thanks to David)
logged by Joan:
https://github.com/apache/couchdb-fauxton/issues/1099
https://github.com/apache/couchdb-fauxton/issues/1100
--------------------------------------------------------------------------------------------------
I left aside reports of 1.x behaviour not possible to add to 2.x (ref Jans respons)
> On 5 Jul 2018, at 17:46, Joan Touzet <wo...@apache.org> wrote:
>
>> On 2018-07-05 09:10, Johs Ensby wrote:
>>
>>> This thread reach out to CouchDB 1.x users to generate a list of
>>> "must-fix" issues that is preventing users to upgrade to the latest
>>> version of CouchDB.
>>>
>>> It is in response to Joan's comment below regarding the
>>> non-technical proposal to make a project decision to terminate
>>> official Apache support for CouchDB 1.x.
>>>
>>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>>
>>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>>> too would like to see pull requests for those. Once again, your help is
>>>> most welcome in this - both in identifying a definitive list of those
>>>> must-fix issues, as well as code towards fixing them. If you'd like
>>>> to help with this important work, please start a new thread.
>>>
>>> Mine is CouchDB as a proxy.
>>> The feature described here is not working in 2.1.1
>>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>>
>>> Johs
Re: Call for "Must-fix" issues
Posted by Joan Touzet <wo...@apache.org>.
Thanks for the ideas, David!
I've logged these two requests with Fauxton here:
https://github.com/apache/couchdb-fauxton/issues/1099
https://github.com/apache/couchdb-fauxton/issues/1100
-Joan
----- Original Message -----
From: "David Alan Hjelle" <da...@thehjellejar.com>
To: user@couchdb.apache.org
Sent: Thursday, July 5, 2018 11:37:26 AM
Subject: Re: Call for "Must-fix" issues
While this hasn’t kept us back from upgrading to Couch 2, we have run into some similar challenges with Fauxton. I think they would be fairly simply fixed by adding in some UI for functionality already in the Ace editor.
Settings for code folding—it’d be nice (for us) to have the JSON documents folded by default. Even better would be the ability to set a preference as to how many levels should be unfolded by default, and saved in the browser’s local storage or something. That would help us a lot in navigating deeply nested JSON documents where the top levels usually have all the data we need when debugging.
Search functionality. It looks like the browser’s search doesn’t work, since Ace is probably doing virtual scrolling (i.e. only putting the text in the DOM that’s on the screen at the time. Ace appears to have some search functionality, but it would need some UI around it.
Again, they haven’t kept us back from upgrading, but they are some of the concerns I’ve heard from our developers when we *did* upgrade.
David Alan Hjelle
1 Corinthians 2:2
http://thehjellejar.com/ <http://thehjellejar.com/>
<http://thehjellejar.com/>See the church management software I build at Icon Systems, Inc. <http://iconcmo.com/>
Check out Rita’s spoons <http://jarofwood.com/>.
> On Jul 5, 2018, at 2:32 AM, Kai Griffin <ka...@resourceandrevenue.com> wrote:
>
> As developers who spend a lot of time in the CouchDB web interface, we have held back moving to CouchDB 2.x only because of the change from Futon to Fauxton. We feel that Fauxton simply does not meet the needs of developers as well as Futon did. It seems to be targeted more at non-devs: it’s very friendly-looking, modern & pretty, but is biased towards prettifying document JSON, at the expense of being able to scan through many unformatted documents, which Futon does by default.
>
> So, mainly comes down to the inability to properly see the contents of documents without opening up documents individually. We like to see the whole, unformatted document when viewing a list of documents (or, in the case of looking at a View, then whatever the map script outputs, but in an unformatted form, not prettified like Fauxton). Futon is more compact & developer friendly, even if to a non-dev, such views might look like a jumble of unformatted text. At very least, some kind of “classic mode” switch would be greatly welcomed, at least by us :-)
>
> Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and the issue I brought up above might well have been addressed by someone in the meantime, so apologies if I’m dredging up old/non-relevant stuff (in which case we’ll happily jump onto 2.x!)
>
>
> On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it) wrote:
>
> Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
>
> On 2018-07-05 09:10, Johs Ensby wrote:
>
>> This thread reach out to CouchDB 1.x users to generate a list of
>> "must-fix" issues that is preventing users to upgrade to the latest
>> version of CouchDB.
>>
>> It is in response to Joan's comment below regarding the
>> non-technical proposal to make a project decision to terminate
>> official Apache support for CouchDB 1.x.
>>
>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>> too would like to see pull requests for those. Once again, your help is
>>> most welcome in this - both in identifying a definitive list of those
>>> must-fix issues, as well as code towards fixing them. If you'd like
>>> to help with this important work, please start a new thread.
>>
>> Mine is CouchDB as a proxy.
>> The feature described here is not working in 2.1.1
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>
>> Johs
Re: Call for "Must-fix" issues
Posted by David Alan Hjelle <da...@thehjellejar.com>.
While this hasn’t kept us back from upgrading to Couch 2, we have run into some similar challenges with Fauxton. I think they would be fairly simply fixed by adding in some UI for functionality already in the Ace editor.
Settings for code folding—it’d be nice (for us) to have the JSON documents folded by default. Even better would be the ability to set a preference as to how many levels should be unfolded by default, and saved in the browser’s local storage or something. That would help us a lot in navigating deeply nested JSON documents where the top levels usually have all the data we need when debugging.
Search functionality. It looks like the browser’s search doesn’t work, since Ace is probably doing virtual scrolling (i.e. only putting the text in the DOM that’s on the screen at the time. Ace appears to have some search functionality, but it would need some UI around it.
Again, they haven’t kept us back from upgrading, but they are some of the concerns I’ve heard from our developers when we *did* upgrade.
David Alan Hjelle
1 Corinthians 2:2
http://thehjellejar.com/ <http://thehjellejar.com/>
<http://thehjellejar.com/>See the church management software I build at Icon Systems, Inc. <http://iconcmo.com/>
Check out Rita’s spoons <http://jarofwood.com/>.
> On Jul 5, 2018, at 2:32 AM, Kai Griffin <ka...@resourceandrevenue.com> wrote:
>
> As developers who spend a lot of time in the CouchDB web interface, we have held back moving to CouchDB 2.x only because of the change from Futon to Fauxton. We feel that Fauxton simply does not meet the needs of developers as well as Futon did. It seems to be targeted more at non-devs: it’s very friendly-looking, modern & pretty, but is biased towards prettifying document JSON, at the expense of being able to scan through many unformatted documents, which Futon does by default.
>
> So, mainly comes down to the inability to properly see the contents of documents without opening up documents individually. We like to see the whole, unformatted document when viewing a list of documents (or, in the case of looking at a View, then whatever the map script outputs, but in an unformatted form, not prettified like Fauxton). Futon is more compact & developer friendly, even if to a non-dev, such views might look like a jumble of unformatted text. At very least, some kind of “classic mode” switch would be greatly welcomed, at least by us :-)
>
> Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and the issue I brought up above might well have been addressed by someone in the meantime, so apologies if I’m dredging up old/non-relevant stuff (in which case we’ll happily jump onto 2.x!)
>
>
> On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it) wrote:
>
> Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
>
> On 2018-07-05 09:10, Johs Ensby wrote:
>
>> This thread reach out to CouchDB 1.x users to generate a list of
>> "must-fix" issues that is preventing users to upgrade to the latest
>> version of CouchDB.
>>
>> It is in response to Joan's comment below regarding the
>> non-technical proposal to make a project decision to terminate
>> official Apache support for CouchDB 1.x.
>>
>>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> As for things in 2.x that are "must fix" before people can upgrade, I
>>> too would like to see pull requests for those. Once again, your help is
>>> most welcome in this - both in identifying a definitive list of those
>>> must-fix issues, as well as code towards fixing them. If you'd like
>>> to help with this important work, please start a new thread.
>>
>> Mine is CouchDB as a proxy.
>> The feature described here is not working in 2.1.1
>> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>>
>> Johs
Re: Call for "Must-fix" issues
Posted by Kai Griffin <ka...@resourceandrevenue.com>.
As developers who spend a lot of time in the CouchDB web interface, we have held back moving to CouchDB 2.x only because of the change from Futon to Fauxton. We feel that Fauxton simply does not meet the needs of developers as well as Futon did. It seems to be targeted more at non-devs: it’s very friendly-looking, modern & pretty, but is biased towards prettifying document JSON, at the expense of being able to scan through many unformatted documents, which Futon does by default.
So, mainly comes down to the inability to properly see the contents of documents without opening up documents individually. We like to see the whole, unformatted document when viewing a list of documents (or, in the case of looking at a View, then whatever the map script outputs, but in an unformatted form, not prettified like Fauxton). Futon is more compact & developer friendly, even if to a non-dev, such views might look like a jumble of unformatted text. At very least, some kind of “classic mode” switch would be greatly welcomed, at least by us :-)
Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and the issue I brought up above might well have been addressed by someone in the meantime, so apologies if I’m dredging up old/non-relevant stuff (in which case we’ll happily jump onto 2.x!)
On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it) wrote:
Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
On 2018-07-05 09:10, Johs Ensby wrote:
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>
>> As for things in 2.x that are "must fix" before people can upgrade, I
>> too would like to see pull requests for those. Once again, your help is
>> most welcome in this - both in identifying a definitive list of those
>> must-fix issues, as well as code towards fixing them. If you'd like
>> to help with this important work, please start a new thread.
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
Re: Call for "Must-fix" issues
Posted by Kai Griffin <ka...@resourceandrevenue.com>.
As developers who spend a lot of time in the CouchDB web interface, we have held back moving to CouchDB 2.x only because of the change from Futon to Fauxton. We feel that Fauxton simply does not meet the needs of developers as well as Futon did. It seems to be targeted more at non-devs: it’s very friendly-looking, modern & pretty, but is biased towards prettifying document JSON, at the expense of being able to scan through many unformatted documents, which Futon does by default.
So, mainly comes down to the inability to properly see the contents of documents without opening up documents individually. We like to see the whole, unformatted document when viewing a list of documents (or, in the case of looking at a View, then whatever the map script outputs, but in an unformatted form, not prettified like Fauxton). Futon is more compact & developer friendly, even if to a non-dev, such views might look like a jumble of unformatted text. At very least, some kind of “classic mode” switch would be greatly welcomed, at least by us :-)
Please note that it’s been awhile since I’ve looked at CouchDB 2.x, and the issue I brought up above might well have been addressed by someone in the meantime, so apologies if I’m dredging up old/non-relevant stuff (in which case we’ll happily jump onto 2.x!)
On 5 July 2018 at 09:21:37, Andrea Brancatelli (abrancatelli@schema31.it) wrote:
Well, mine is the lack for a working FreeBSD port for CouchDB 2.x...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844
On 2018-07-05 09:10, Johs Ensby wrote:
> This thread reach out to CouchDB 1.x users to generate a list of
> "must-fix" issues that is preventing users to upgrade to the latest
> version of CouchDB.
>
> It is in response to Joan's comment below regarding the
> non-technical proposal to make a project decision to terminate
> official Apache support for CouchDB 1.x.
>
>> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>>
>> As for things in 2.x that are "must fix" before people can upgrade, I
>> too would like to see pull requests for those. Once again, your help is
>> most welcome in this - both in identifying a definitive list of those
>> must-fix issues, as well as code towards fixing them. If you'd like
>> to help with this important work, please start a new thread.
>
> Mine is CouchDB as a proxy.
> The feature described here is not working in 2.1.1
> http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
>
> Johs
Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
This thread reach out to CouchDB 1.x users to generate a list of
"must-fix" issues that is preventing users to upgrade to the latest
version of CouchDB.
It is in response to Joan's comment below regarding the
non-technical proposal to make a project decision to terminate
official Apache support for CouchDB 1.x.
> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>
> As for things in 2.x that are "must fix" before people can upgrade, I
> too would like to see pull requests for those. Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.
Mine is CouchDB as a proxy.
The feature described here is not working in 2.1.1
http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
Johs
Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
This thread reach out to CouchDB 1.x users to generate a list of
"must-fix" issues that is preventing users to upgrade to the latest
version of CouchDB.
It is in response to Joan's comment below regarding the
non-technical proposal to make a project decision to terminate
official Apache support for CouchDB 1.x.
> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>
> As for things in 2.x that are "must fix" before people can upgrade, I
> too would like to see pull requests for those. Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.
Mine is CouchDB as a proxy.
The feature described here is not working in 2.1.1
http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
Johs
Call for "Must-fix" issues
Posted by Johs Ensby <jo...@b2w.com>.
This thread reach out to CouchDB 1.x users to generate a list of
"must-fix" issues that is preventing users to upgrade to the latest
version of CouchDB.
It is in response to Joan's comment below regarding the
non-technical proposal to make a project decision to terminate
official Apache support for CouchDB 1.x.
> On 5 Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>
> As for things in 2.x that are "must fix" before people can upgrade, I
> too would like to see pull requests for those. Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.
Mine is CouchDB as a proxy.
The feature described here is not working in 2.1.1
http://docs.couchdb.org/en/2.1.1/config/proxying.html?highlight=_proxy
Johs
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Johs,
while I understand that corporate policies involved with saying a
version is end-of-life (e.g. “we must migrate off it”), there is
nobody stopping anyone from continuing to run 1.x in a setup where
it is already running fine and security updates are not a concern.
In fact we have a number of customers that we’d advise to continue
to stay on 1.x, despite the potential deprecation.
As such, I’m not seeing this proposal as “the kill switch”, as you
call it. There is merely making policy what has been reality for the
better part of two years in terms of focus for the team.
Whatever “reputation damage” is there, we have already incurred it.
Best
Jan
--
> On 5. Jul 2018, at 06:31, Joan Touzet <wo...@apache.org> wrote:
>
> Hi Johs,
>
> Pull requests for 1.x continue to be welcome. But it's been almost two
> years since 2.0.0 was released - and I've seen none beyond trivial bug
> fixes. Were this proposal not to proceed, the only thing that would
> continue right now for 1.x is urgent security patches.
>
> I have already consulted with the active developers working on the
> master / 2.x branches - none have the time or inclination to continue
> working on 1.x backports, so there is no group of developers currently
> identified to fill that hypothetical 3-man team. Are you volunteering?
>
> I'm not saying "no" to backporting, but I am saying that no one has done
> so to date, and making a prediction that chances are very slim that
> it'll change in the foreseeable future.
>
> As for things in 2.x that are "must fix" before people can upgrade, I
> too would like to see pull requests for those. Once again, your help is
> most welcome in this - both in identifying a definitive list of those
> must-fix issues, as well as code towards fixing them. If you'd like
> to help with this important work, please start a new thread.
>
> I realize we see things differently from where we each sit, but 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. I feel
> as a result the time is right to make this proposal.
>
> Thanks for your feedback.
>
> -Joan
>
>
> ----- Original Message -----
> From: "Johs Ensby" <jo...@b2w.com>
> To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>, "Joan Touzet" <wo...@apache.org>
> Sent: Wednesday, July 4, 2018 6:06:06 PM
> Subject: Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
>
> Joan,
> thanks for your relentless effort to focus resources on moving 2.x forward.
> That said, I honestly dont see how this proposal would support your intentions
>
> 1) Migration to to 2.x would have happened already if a production ready version was available
> 2) Leaving 1.x out in the cold will not speed up migration to 2.x for the above reason
> 3) To drop support before migration is a success is a very risky move
>
> To me this is a reputation killer. When forward-looking decisions are made for or against the use of CouchDB, a minimum of two things must be in place. Confidence in the team pushing the next version forward and a commitment to keep supporting the users that want, but cannot upgrade as they wait for critical issues to be solved.
>
> My suggestion would be to move with some of the hopeful suggestions to see if some new resources would come out of the woodwork
> 1) A 3-person team should be actively encouraged into existence as a first step of a longer process
> 2) Your "no" to back-porting is reasonable if it draws resources from the main project, otherwise why curb the enthusiasm?
> 3) The decision to freeze (not abandon) should come as a consquense of 2.x fully satisfying the users with 1.x systems in production
>
> br
> Johs
>
>
>> 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
>
>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Joan Touzet <wo...@apache.org>.
Hi Johs,
Pull requests for 1.x continue to be welcome. But it's been almost two
years since 2.0.0 was released - and I've seen none beyond trivial bug
fixes. Were this proposal not to proceed, the only thing that would
continue right now for 1.x is urgent security patches.
I have already consulted with the active developers working on the
master / 2.x branches - none have the time or inclination to continue
working on 1.x backports, so there is no group of developers currently
identified to fill that hypothetical 3-man team. Are you volunteering?
I'm not saying "no" to backporting, but I am saying that no one has done
so to date, and making a prediction that chances are very slim that
it'll change in the foreseeable future.
As for things in 2.x that are "must fix" before people can upgrade, I
too would like to see pull requests for those. Once again, your help is
most welcome in this - both in identifying a definitive list of those
must-fix issues, as well as code towards fixing them. If you'd like
to help with this important work, please start a new thread.
I realize we see things differently from where we each sit, but 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. I feel
as a result the time is right to make this proposal.
Thanks for your feedback.
-Joan
----- Original Message -----
From: "Johs Ensby" <jo...@b2w.com>
To: "dev@couchdb.apache.org Developers" <de...@couchdb.apache.org>, "Joan Touzet" <wo...@apache.org>
Sent: Wednesday, July 4, 2018 6:06:06 PM
Subject: Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Joan,
thanks for your relentless effort to focus resources on moving 2.x forward.
That said, I honestly dont see how this proposal would support your intentions
1) Migration to to 2.x would have happened already if a production ready version was available
2) Leaving 1.x out in the cold will not speed up migration to 2.x for the above reason
3) To drop support before migration is a success is a very risky move
To me this is a reputation killer. When forward-looking decisions are made for or against the use of CouchDB, a minimum of two things must be in place. Confidence in the team pushing the next version forward and a commitment to keep supporting the users that want, but cannot upgrade as they wait for critical issues to be solved.
My suggestion would be to move with some of the hopeful suggestions to see if some new resources would come out of the woodwork
1) A 3-person team should be actively encouraged into existence as a first step of a longer process
2) Your "no" to back-porting is reasonable if it draws resources from the main project, otherwise why curb the enthusiasm?
3) The decision to freeze (not abandon) should come as a consquense of 2.x fully satisfying the users with 1.x systems in production
br
Johs
> 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Johs Ensby <jo...@b2w.com>.
Joan,
thanks for your relentless effort to focus resources on moving 2.x forward.
That said, I honestly dont see how this proposal would support your intentions
1) Migration to to 2.x would have happened already if a production ready version was available
2) Leaving 1.x out in the cold will not speed up migration to 2.x for the above reason
3) To drop support before migration is a success is a very risky move
To me this is a reputation killer. When forward-looking decisions are made for or against the use of CouchDB, a minimum of two things must be in place. Confidence in the team pushing the next version forward and a commitment to keep supporting the users that want, but cannot upgrade as they wait for critical issues to be solved.
My suggestion would be to move with some of the hopeful suggestions to see if some new resources would come out of the woodwork
1) A 3-person team should be actively encouraged into existence as a first step of a longer process
2) Your "no" to back-porting is reasonable if it draws resources from the main project, otherwise why curb the enthusiasm?
3) The decision to freeze (not abandon) should come as a consquense of 2.x fully satisfying the users with 1.x systems in production
br
Johs
> 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by 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
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Ilya Khlopotov <ii...@apache.org>.
As you've said there are no big contributions to 1.x branches for few years.
I am not sure how many users use 1.x releases.
However, I do believe that spending resources on releases for very old versions is counterproductive.
It would be better for the project if these resources would be spent elsewhere.
I am in favor of deprecating 1.x
Best regards,
@iilyak
On 2018/07/04 20:51:15, 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
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Joan Touzet <wo...@apache.org>.
I'd like to know more about this point:
> Just to have our pull requests rejected? No thanks, We learned
> something from the past.
Developer goodwill is definitely in the interest of the PMC. I am
troubled to hear that you had difficulty landing your PRs.
Could you link to the PRs in question?
What were the reasons your PRs were rejected?
If constructive criticism was provided, were there reasons you were
unable to make the requested changes to your PR?
-Joan
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Giovanni Lenzi <g....@smileupps.com>.
On Fri, Jul 6, 2018, 15:48 Jan Lehnardt <ja...@apache.org> wrote:
>
>
> > On 6. Jul 2018, at 15:27, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >
> >
> >> On 6. Jul 2018, at 15:00, Giovanni Lenzi <g....@smileupps.com> wrote:
> >>
> >> -1
> >>
> >> Since the release of CouchDB 2.x, we noticed a lot of new users coming
> to
> >> Smileupps.com, where we provide 1.x support. Almost all our customers
> feel
> >> that 1.x is very reliable and very simple to get their job done. On the
> >> contrary 2.x is perceived as heavy, buggy, and not production ready. I
> >> report here some thoughts directly reported from Smileupps customers:
> >>
> >> - CouchDB 2 has lot of bugs and open issues, not felt suitable for
> >> production
> >> - Too difficult to migrate
> >> - Interested in having simple Couch on a single node
> >> - 2 is too slow in single node configuration
> >> - Interested in 1.x couchapps and _changes
> >>
> >> From our experience, developers are much more interested in features
> >> decreasing their development time and easing their daily work( Futon UI
> /
> >> design docs / rewrites ), instead of system features, like clustering,
> >> which can eventually be obtained in other functionally similar ways at
> >> higher or lower levels.
> >>
> >> I'm quite sure that deprecating 1.x will leave thousands of Couchdb
> users
> >> in a state of limbo withouth real alternatives felt as reliable. That
> would
> >> be definitely a reputation killer for the whole Couch project
> >
> > Would you be up for making some of our resources available for
> maintaining
> > 1.x?
>
> *your resources
>
> Apologies
>
Just to have our pull requests rejected? No thanks, We learned something
from the past.
Just take what I said as a big and free survey to your users and their
needs.. After that, you are free to develop what it makes you feel better
> >
> >
> >>
> >>
> >> --Giovanni
> >>
> >> 2018-07-05 19:43 GMT+02:00 Alexander Shorin <kx...@gmail.com>:
> >>
> >>> 1.x, you was good and we'll never forget you, but it's time to move
> >>> forward to better CouchDB future.
> >>>
> >>> +1, bury it!
> >>> --
> >>> ,,,^..^,,,
> >>>
> >>>
> >>> On Wed, Jul 4, 2018 at 11:51 PM, 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
> >>>
> >
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Jan Lehnardt <ja...@apache.org>.
> On 6. Jul 2018, at 15:27, Jan Lehnardt <ja...@apache.org> wrote:
>
>
>
>> On 6. Jul 2018, at 15:00, Giovanni Lenzi <g....@smileupps.com> wrote:
>>
>> -1
>>
>> Since the release of CouchDB 2.x, we noticed a lot of new users coming to
>> Smileupps.com, where we provide 1.x support. Almost all our customers feel
>> that 1.x is very reliable and very simple to get their job done. On the
>> contrary 2.x is perceived as heavy, buggy, and not production ready. I
>> report here some thoughts directly reported from Smileupps customers:
>>
>> - CouchDB 2 has lot of bugs and open issues, not felt suitable for
>> production
>> - Too difficult to migrate
>> - Interested in having simple Couch on a single node
>> - 2 is too slow in single node configuration
>> - Interested in 1.x couchapps and _changes
>>
>> From our experience, developers are much more interested in features
>> decreasing their development time and easing their daily work( Futon UI /
>> design docs / rewrites ), instead of system features, like clustering,
>> which can eventually be obtained in other functionally similar ways at
>> higher or lower levels.
>>
>> I'm quite sure that deprecating 1.x will leave thousands of Couchdb users
>> in a state of limbo withouth real alternatives felt as reliable. That would
>> be definitely a reputation killer for the whole Couch project
>
> Would you be up for making some of our resources available for maintaining
> 1.x?
*your resources
Apologies.
>
>
>>
>>
>> --Giovanni
>>
>> 2018-07-05 19:43 GMT+02:00 Alexander Shorin <kx...@gmail.com>:
>>
>>> 1.x, you was good and we'll never forget you, but it's time to move
>>> forward to better CouchDB future.
>>>
>>> +1, bury it!
>>> --
>>> ,,,^..^,,,
>>>
>>>
>>> On Wed, Jul 4, 2018 at 11:51 PM, 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
>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Jan Lehnardt <ja...@apache.org>.
> On 6. Jul 2018, at 15:00, Giovanni Lenzi <g....@smileupps.com> wrote:
>
> -1
>
> Since the release of CouchDB 2.x, we noticed a lot of new users coming to
> Smileupps.com, where we provide 1.x support. Almost all our customers feel
> that 1.x is very reliable and very simple to get their job done. On the
> contrary 2.x is perceived as heavy, buggy, and not production ready. I
> report here some thoughts directly reported from Smileupps customers:
>
> - CouchDB 2 has lot of bugs and open issues, not felt suitable for
> production
> - Too difficult to migrate
> - Interested in having simple Couch on a single node
> - 2 is too slow in single node configuration
> - Interested in 1.x couchapps and _changes
>
> From our experience, developers are much more interested in features
> decreasing their development time and easing their daily work( Futon UI /
> design docs / rewrites ), instead of system features, like clustering,
> which can eventually be obtained in other functionally similar ways at
> higher or lower levels.
>
> I'm quite sure that deprecating 1.x will leave thousands of Couchdb users
> in a state of limbo withouth real alternatives felt as reliable. That would
> be definitely a reputation killer for the whole Couch project
Would you be up for making some of our resources available for maintaining
1.x?
>
>
> --Giovanni
>
> 2018-07-05 19:43 GMT+02:00 Alexander Shorin <kx...@gmail.com>:
>
>> 1.x, you was good and we'll never forget you, but it's time to move
>> forward to better CouchDB future.
>>
>> +1, bury it!
>> --
>> ,,,^..^,,,
>>
>>
>> On Wed, Jul 4, 2018 at 11:51 PM, 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
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Giovanni Lenzi <g....@smileupps.com>.
-1
Since the release of CouchDB 2.x, we noticed a lot of new users coming to
Smileupps.com, where we provide 1.x support. Almost all our customers feel
that 1.x is very reliable and very simple to get their job done. On the
contrary 2.x is perceived as heavy, buggy, and not production ready. I
report here some thoughts directly reported from Smileupps customers:
- CouchDB 2 has lot of bugs and open issues, not felt suitable for
production
- Too difficult to migrate
- Interested in having simple Couch on a single node
- 2 is too slow in single node configuration
- Interested in 1.x couchapps and _changes
From our experience, developers are much more interested in features
decreasing their development time and easing their daily work( Futon UI /
design docs / rewrites ), instead of system features, like clustering,
which can eventually be obtained in other functionally similar ways at
higher or lower levels.
I'm quite sure that deprecating 1.x will leave thousands of Couchdb users
in a state of limbo withouth real alternatives felt as reliable. That would
be definitely a reputation killer for the whole Couch project
--Giovanni
2018-07-05 19:43 GMT+02:00 Alexander Shorin <kx...@gmail.com>:
> 1.x, you was good and we'll never forget you, but it's time to move
> forward to better CouchDB future.
>
> +1, bury it!
> --
> ,,,^..^,,,
>
>
> On Wed, Jul 4, 2018 at 11:51 PM, 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
>
Re: [PROPOSAL] Officially deprecate CouchDB 1.x.
Posted by Alexander Shorin <kx...@gmail.com>.
1.x, you was good and we'll never forget you, but it's time to move
forward to better CouchDB future.
+1, bury it!
--
,,,^..^,,,
On Wed, Jul 4, 2018 at 11:51 PM, 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