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

[Alexander Shorin]

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  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

[NEWS] The CouchDB weekly news for July 5th is out!

[Emily Daves]

Hello hello!



The Apache CouchDB weekly news is now live at:

http://blog.couchdb.org/2018/07/05/couchdb-weekly-news-july-5-2018



Highlights include new releases in the CouchDB universe, some tutorials on
Hyperledger Fabric, and a great idea to reduce wildfires caused by firework
displays--drone displays!



If you have news for the next issue, just REPLY to this thread!



Cheers!



Emily Daves

The Neighbourhoodie Software GmbH

Ohlauer Str. 43, 10999 Berlin


neighbourhood.ie



Handelsregister HRB 157851 B Amtsgericht Charlottenburg

Geschäftsführung: Jan Lehnardt

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

[Paul Davis]

+1
On Thu, Jul 5, 2018 at 5:18 AM Andy Wenk  wrote:
>
> +1
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> GPG public key:
> http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29
>
>
>
> > On 5. Jul 2018, at 11:21, Garren Smith  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 
> > 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  wrote:
> >>>
> >>>
> >>>
>  On 4. Jul 2018, at 22:51, Joan Touzet  wrote:
> 
>  DISCLAIMER: This is a non-technical proposal to make a project decision.
>  Per our Bylaws[1], this means that it should "normally be made with lazy
>  consensus, or by the entire community using discussion-led
>  consensus-building, and not through formal voting." However, since the
>  intent is to make a significant policy change, this concrete proposal
>  should be considered as a *lazy consensus* decision with a *7 day*
>  timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
>  thread your ample consideration.
> 
> 
>  I would like to table[2] a proposal to terminate official Apache support
>  for CouchDB 1.x. This means that:
> 
>  1. The Apache CouchDB project will no longer make new 1.x releases.
>  2. All remaining 1.x issues in JIRA and GH Issues will be closed.
>  3. Everyone can continue to use 1.x as long as they want.
>  4. People are welcome to continue discussing 1.x on the users@ list.
> 
> 
>  The reason is simple: no one is maintaining the 1.x.x branches of
>  CouchDB anymore. Issues stack up on the tracker[3] with no response.
>  Original grand plans of back-porting 2.x features such as Mango to 1.x
>  have not materialised. And when important security issues surface[4],
>  having to patch 1.x as well as 2.x slows down the security team's
>  ability to push releases quickly out the door.
> 
>  By focusing on what we do best - supporting 2.x and beyond with bug
>  fixes, new features, and ever-improving documentation and web UI - we
>  can improve our release cadence and avoid misleading our user base
>  with false promises.
> 
> 
>  THAT SAID: There are two important footnotes to the proposal.
> 
>  FIRST: If a group of interested maintainers start making active efforts
>  to improve 1.x branch upkeep, I can speak with the full authority of the
>  PMC to say that we'll endorse those efforts. But to un-mothball
>  1.x officially should require more than 1-2 people doing occasional
>  bugfixing work. I'd personally want to see at least a 3-person team
>  making sustained contributions to 1.x before re-activating official
>  releases. Also, that work would need to be in-line with work currently
>  happening on master; I wouldn't want to see new 1.x features materialise
>  that don't have parallel 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: Call for "Must-fix" issues

[Jan Lehnardt]

> On 5. Jul 2018, at 13:54, Mad, Pink and Dangerous to Know  
> 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  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  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

[Mad, Pink and Dangerous to Know]

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

[Andy Wenk]

+1

--
Andy Wenk
Hamburg - Germany
RockIt!

GPG public key:
http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29



> On 5. Jul 2018, at 11:21, Garren Smith  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 
> 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  wrote:
>>> 
>>> 
>>> 
 On 4. Jul 2018, at 22:51, Joan Touzet  wrote:
 
 DISCLAIMER: This is a non-technical proposal to make a project decision.
 Per our Bylaws[1], this means that it should "normally be made with lazy
 consensus, or by the entire community using discussion-led
 consensus-building, and not through formal voting." However, since the
 intent is to make a significant policy change, this concrete proposal
 should be considered as a *lazy consensus* decision with a *7 day*
 timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
 thread your ample consideration.
 
 
 I would like to table[2] a proposal to terminate official Apache support
 for CouchDB 1.x. This means that:
 
 1. The Apache CouchDB project will no longer make new 1.x releases.
 2. All remaining 1.x issues in JIRA and GH Issues will be closed.
 3. Everyone can continue to use 1.x as long as they want.
 4. People are welcome to continue discussing 1.x on the users@ list.
 
 
 The reason is simple: no one is maintaining the 1.x.x branches of
 CouchDB anymore. Issues stack up on the tracker[3] with no response.
 Original grand plans of back-porting 2.x features such as Mango to 1.x
 have not materialised. And when important security issues surface[4],
 having to patch 1.x as well as 2.x slows down the security team's
 ability to push releases quickly out the door.
 
 By focusing on what we do best - supporting 2.x and beyond with bug
 fixes, new features, and ever-improving documentation and web UI - we
 can improve our release cadence and avoid misleading our user base
 with false promises.
 
 
 THAT SAID: There are two important footnotes to the proposal.
 
 FIRST: If a group of interested maintainers start making active efforts
 to improve 1.x branch upkeep, I can speak with the full authority of the
 PMC to say that we'll endorse those efforts. But to un-mothball
 1.x officially should require more than 1-2 people doing occasional
 bugfixing work. I'd personally want to see at least a 3-person team
 making sustained contributions to 1.x before re-activating official
 releases. Also, that work would need to be in-line with work currently
 happening on master; I wouldn't want to see new 1.x features materialise
 that don't have parallel 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/
>> 
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Call for "Must-fix" issues

[Kai Griffin]

Thanks, Garren,  
I’ll look for that in the latest release. But for this, I’d certainly prefer us 
to migrate to 2.x
Cheers,
Kai


On 5 July 2018 at 11:16:11, Garren Smith 
(gar...@apache.org(mailto:gar...@apache.org)) wrote:

> 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 
> 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 (abrancate...@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  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.

[Garren Smith]

+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 
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  wrote:
> >
> >
> >
> >> On 4. Jul 2018, at 22:51, Joan Touzet  wrote:
> >>
> >> DISCLAIMER: This is a non-technical proposal to make a project decision.
> >> Per our Bylaws[1], this means that it should "normally be made with lazy
> >> consensus, or by the entire community using discussion-led
> >> consensus-building, and not through formal voting." However, since the
> >> intent is to make a significant policy change, this concrete proposal
> >> should be considered as a *lazy consensus* decision with a *7 day*
> >> timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
> >> thread your ample consideration.
> >>
> >>
> >> I would like to table[2] a proposal to terminate official Apache support
> >> for CouchDB 1.x. This means that:
> >>
> >> 1. The Apache CouchDB project will no longer make new 1.x releases.
> >> 2. All remaining 1.x issues in JIRA and GH Issues will be closed.
> >> 3. Everyone can continue to use 1.x as long as they want.
> >> 4. People are welcome to continue discussing 1.x on the users@ list.
> >>
> >>
> >> The reason is simple: no one is maintaining the 1.x.x branches of
> >> CouchDB anymore. Issues stack up on the tracker[3] with no response.
> >> Original grand plans of back-porting 2.x features such as Mango to 1.x
> >> have not materialised. And when important security issues surface[4],
> >> having to patch 1.x as well as 2.x slows down the security team's
> >> ability to push releases quickly out the door.
> >>
> >> By focusing on what we do best - supporting 2.x and beyond with bug
> >> fixes, new features, and ever-improving documentation and web UI - we
> >> can improve our release cadence and avoid misleading our user base
> >> with false promises.
> >>
> >>
> >> THAT SAID: There are two important footnotes to the proposal.
> >>
> >> FIRST: If a group of interested maintainers start making active efforts
> >> to improve 1.x branch upkeep, I can speak with the full authority of the
> >> PMC to say that we'll endorse those efforts. But to un-mothball
> >> 1.x officially should require more than 1-2 people doing occasional
> >> bugfixing work. I'd personally want to see at least a 3-person team
> >> making sustained contributions to 1.x before re-activating official
> >> releases. Also, that work would need to be in-line with work currently
> >> happening on master; I wouldn't want to see new 1.x features materialise
> >> that don't have parallel 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: Call for "Must-fix" issues

[Garren Smith]

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 
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 (abrancate...@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  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.

[Robert Samuel Newson]

+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  wrote:
> 
> 
> 
>> On 4. Jul 2018, at 22:51, Joan Touzet  wrote:
>> 
>> DISCLAIMER: This is a non-technical proposal to make a project decision.
>> Per our Bylaws[1], this means that it should "normally be made with lazy
>> consensus, or by the entire community using discussion-led
>> consensus-building, and not through formal voting." However, since the
>> intent is to make a significant policy change, this concrete proposal
>> should be considered as a *lazy consensus* decision with a *7 day*
>> timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
>> thread your ample consideration.
>> 
>> 
>> I would like to table[2] a proposal to terminate official Apache support
>> for CouchDB 1.x. This means that:
>> 
>> 1. The Apache CouchDB project will no longer make new 1.x releases.
>> 2. All remaining 1.x issues in JIRA and GH Issues will be closed.
>> 3. Everyone can continue to use 1.x as long as they want.
>> 4. People are welcome to continue discussing 1.x on the users@ list.
>> 
>> 
>> The reason is simple: no one is maintaining the 1.x.x branches of
>> CouchDB anymore. Issues stack up on the tracker[3] with no response.
>> Original grand plans of back-porting 2.x features such as Mango to 1.x
>> have not materialised. And when important security issues surface[4],
>> having to patch 1.x as well as 2.x slows down the security team's
>> ability to push releases quickly out the door.
>> 
>> By focusing on what we do best - supporting 2.x and beyond with bug
>> fixes, new features, and ever-improving documentation and web UI - we
>> can improve our release cadence and avoid misleading our user base
>> with false promises.
>> 
>> 
>> THAT SAID: There are two important footnotes to the proposal.
>> 
>> FIRST: If a group of interested maintainers start making active efforts
>> to improve 1.x branch upkeep, I can speak with the full authority of the
>> PMC to say that we'll endorse those efforts. But to un-mothball
>> 1.x officially should require more than 1-2 people doing occasional
>> bugfixing work. I'd personally want to see at least a 3-person team
>> making sustained contributions to 1.x before re-activating official
>> releases. Also, that work would need to be in-line with work currently
>> happening on master; I wouldn't want to see new 1.x features materialise
>> that don't have parallel 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.

[Jan Lehnardt]

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  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" 
> To: "dev@couchdb.apache.org Developers" , "Joan 
> Touzet" 
> 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  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 

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

[Jan Lehnardt]

> On 4. Jul 2018, at 22:51, Joan Touzet  wrote:
> 
> DISCLAIMER: This is a non-technical proposal to make a project decision.
> Per our Bylaws[1], this means that it should "normally be made with lazy
> consensus, or by the entire community using discussion-led
> consensus-building, and not through formal voting." However, since the
> intent is to make a significant policy change, this concrete proposal
> should be considered as a *lazy consensus* decision with a *7 day*
> timeframe (expiring on or about 2017-07-11, 23:59 UTC. Please give this
> thread your ample consideration.
> 
> 
> I would like to table[2] a proposal to terminate official Apache support
> for CouchDB 1.x. This means that:
> 
>  1. The Apache CouchDB project will no longer make new 1.x releases.
>  2. All remaining 1.x issues in JIRA and GH Issues will be closed.
>  3. Everyone can continue to use 1.x as long as they want.
>  4. People are welcome to continue discussing 1.x on the users@ list.
> 
> 
> The reason is simple: no one is maintaining the 1.x.x branches of
> CouchDB anymore. Issues stack up on the tracker[3] with no response.
> Original grand plans of back-porting 2.x features such as Mango to 1.x
> have not materialised. And when important security issues surface[4],
> having to patch 1.x as well as 2.x slows down the security team's
> ability to push releases quickly out the door.
> 
> By focusing on what we do best - supporting 2.x and beyond with bug
> fixes, new features, and ever-improving documentation and web UI - we
> can improve our release cadence and avoid misleading our user base
> with false promises.
> 
> 
> THAT SAID: There are two important footnotes to the proposal.
> 
> FIRST: If a group of interested maintainers start making active efforts
> to improve 1.x branch upkeep, I can speak with the full authority of the
> PMC to say that we'll endorse those efforts. But to un-mothball
> 1.x officially should require more than 1-2 people doing occasional
> bugfixing work. I'd personally want to see at least a 3-person team
> making sustained contributions to 1.x before re-activating official
> releases. Also, that work would need to be in-line with work currently
> happening on master; I wouldn't want to see new 1.x features materialise
> that don't have parallel 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: Call for "Must-fix" issues

[Kai Griffin]

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 (abrancate...@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  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

[Johs Ensby]

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

[Johs Ensby]

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  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" 
> To: "dev@couchdb.apache.org Developers" , "Joan 
> Touzet" 
> 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  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.
>>