Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

[Jan Lehnardt]

In no rush over here. o/

Get well soon!

Cheers
Jan
—

> On 20. Feb 2019, at 23:01, Joan Touzet  wrote:
> 
> sorry everyone, out for medical reasons until Friday, will try and test
> then on Windows and give a vote then
> 
> can you extend the vote for me? thanks
> 
> -Joan
> 
> - Original Message -
>> From: "Nick Vatamaniuc" 
>> To: dev@couchdb.apache.org
>> Sent: Tuesday, February 19, 2019 12:26:41 PM
>> Subject: Re: [VOTE] Release Apache CouchDB 2.3.1 RC2
>> 
>> On CentOS 7 VM, Erlang 20
>> 
>> Signature and checksums ok.
>> make check passes
>> make release worked and couchdb starts
>> Fauxton "verify installation" all green
>> 
>> +1
>> 
>>> On Tue, Feb 19, 2019 at 9:49 AM Jan Lehnardt  wrote:
>>> 
>>> 臘‍♂️ fixed
>>> 
 On 19. Feb 2019, at 15:30, Robert Newson 
 wrote:
 
 the sha256 file exists but is zero bytes long.
 
 --
 Robert Samuel Newson
 rnew...@apache.org
 
> On Tue, 19 Feb 2019, at 13:03, Jan Lehnardt wrote:
> 
> 
>> On 19. Feb 2019, at 13:14, Robert Newson 
>> wrote:
>> 
>> sha512 checksum - verified
>> sha256 checksum - missing
> 
> musta been a case of the eventual consistencies, the file should
> be
>>> there now.
> 
>> signature - good
>> 
>> eunit tests - pass
>> js tests - crashes at delayed_commits.js with
>> 
>> "test/javascript/tests/delayed_commits.js
>>  Error: Failed to execute HTTP request: Failed to connect to
>>> 127.0.0.1 port 15984: Connection refused”
> 
> Funny this one, I thought this was local to my setup s I had no
> one
>>> else
> complain about it. AFAICT it’s a mac only issue that I went
> see-no-evil-
> monkey on since I couldn’t be bothered to have more than a
> cursory
>>> look,
> which I had and nothing stood out. Personally, I’m treating this
> as
> “wontfix, wait for elixir suite”. Happy to take it out of the
> list of
> tests until then, but shoulnd’t IMHO block the release.
> 
> Best
> Jan
> —
> 
> 
>> 
>> 
>> --
>> Robert Samuel Newson
>> rnew...@apache.org
>> 
>>> On Tue, 19 Feb 2019, at 11:20, Jan Lehnardt wrote:
>>> Convenience Mac binary is up here:
>>> https://dist.apache.org/repos/dist/dev/couchdb/binary/mac/2.3.1/rc.2/
>>> 
>>> Best
>>> Jan
>>> —
 On 19. Feb 2019, at 12:13, Jan Lehnardt 
 wrote:
 
 Dear community,
 
 I would like to propose that we release Apache CouchDB
 2.3.1-RC2.
 
 Candidate release notes:
 
 https://docs.couchdb.org/en/2.3.1/whatsnew/2.3.html#version-2-3-1
 
 Changes since last time:
 
 - built rebar with Erlang 17.4.1 (h/t Nick)
 
 We encourage the whole community to download and test these
 release
>>> artefacts so that any critical issues can be resolved before the
>>> release is
>>> made. Everyone is free to vote on this release, so dig right in!
 
 The release artefacts we are voting on are available here:
 
 https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.1/rc.2/
 
 There, you will find a tarball, a GPG signature, and
 SHA256/SHA512
>>> checksums.
 
 Please follow the test procedure here:
 
 
>>> https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
 
 Please remember that "RC2" is an annotation. If the vote
 passes,
>>> these artefacts will be released as Apache CouchDB 2.3.1.
 
 Please cast your votes now.
 
 Thanks,
 Jan
 —
 
> On 17. Feb 2019, at 19:47, Jan Lehnardt 
> wrote:
> 
> Dear community,
> 
> I would like to propose that we release Apache CouchDB
> 2.3.1-RC1.
> 
> Candidate release notes:
> 
> https://docs.couchdb.org/en/2.3.1/whatsnew/2.3.html#version-2-3-1
> 
> We encourage the whole community to download and test these
> release
>>> artefacts so that any critical issues can be resolved before the
>>> release is
>>> made. Everyone is free to vote on this release, so dig right in!
> 
> The release artefacts we are voting on are available here:
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.1/rc.1/
> 
> There, you will find a tarball, a GPG signature, and
> SHA256/SHA512
>>> checksums.
> 
> Please follow the test procedure here:
> 
> 
>>> https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
> 
> Please remember that "RC1" is an annotation. If the vote
> passes,
>>> these artefacts will be released as Apache CouchDB 2.3.1.
> 
> Please cast your votes now.

Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

[Joan Touzet]

sorry everyone, out for medical reasons until Friday, will try and test
then on Windows and give a vote then

can you extend the vote for me? thanks

-Joan

- Original Message -
> From: "Nick Vatamaniuc" 
> To: dev@couchdb.apache.org
> Sent: Tuesday, February 19, 2019 12:26:41 PM
> Subject: Re: [VOTE] Release Apache CouchDB 2.3.1 RC2
> 
> On CentOS 7 VM, Erlang 20
> 
> Signature and checksums ok.
> make check passes
> make release worked and couchdb starts
> Fauxton "verify installation" all green
> 
> +1
> 
> On Tue, Feb 19, 2019 at 9:49 AM Jan Lehnardt  wrote:
> 
> > 臘‍♂️ fixed
> >
> > > On 19. Feb 2019, at 15:30, Robert Newson 
> > > wrote:
> > >
> > > the sha256 file exists but is zero bytes long.
> > >
> > > --
> > >  Robert Samuel Newson
> > >  rnew...@apache.org
> > >
> > > On Tue, 19 Feb 2019, at 13:03, Jan Lehnardt wrote:
> > >>
> > >>
> > >>> On 19. Feb 2019, at 13:14, Robert Newson 
> > >>> wrote:
> > >>>
> > >>> sha512 checksum - verified
> > >>> sha256 checksum - missing
> > >>
> > >> musta been a case of the eventual consistencies, the file should
> > >> be
> > there now.
> > >>
> > >>> signature - good
> > >>>
> > >>> eunit tests - pass
> > >>> js tests - crashes at delayed_commits.js with
> > >>>
> > >>> "test/javascript/tests/delayed_commits.js
> > >>>   Error: Failed to execute HTTP request: Failed to connect to
> > 127.0.0.1 port 15984: Connection refused”
> > >>
> > >> Funny this one, I thought this was local to my setup s I had no
> > >> one
> > else
> > >> complain about it. AFAICT it’s a mac only issue that I went
> > >> see-no-evil-
> > >> monkey on since I couldn’t be bothered to have more than a
> > >> cursory
> > look,
> > >> which I had and nothing stood out. Personally, I’m treating this
> > >> as
> > >> “wontfix, wait for elixir suite”. Happy to take it out of the
> > >> list of
> > >> tests until then, but shoulnd’t IMHO block the release.
> > >>
> > >> Best
> > >> Jan
> > >> —
> > >>
> > >>
> > >>>
> > >>>
> > >>> --
> > >>> Robert Samuel Newson
> > >>> rnew...@apache.org
> > >>>
> > >>> On Tue, 19 Feb 2019, at 11:20, Jan Lehnardt wrote:
> >  Convenience Mac binary is up here:
> >  https://dist.apache.org/repos/dist/dev/couchdb/binary/mac/2.3.1/rc.2/
> > 
> >  Best
> >  Jan
> >  —
> > > On 19. Feb 2019, at 12:13, Jan Lehnardt 
> > > wrote:
> > >
> > > Dear community,
> > >
> > > I would like to propose that we release Apache CouchDB
> > > 2.3.1-RC2.
> > >
> > > Candidate release notes:
> > >
> > > https://docs.couchdb.org/en/2.3.1/whatsnew/2.3.html#version-2-3-1
> > >
> > > Changes since last time:
> > >
> > > - built rebar with Erlang 17.4.1 (h/t Nick)
> > >
> > > We encourage the whole community to download and test these
> > > release
> > artefacts so that any critical issues can be resolved before the
> > release is
> > made. Everyone is free to vote on this release, so dig right in!
> > >
> > > The release artefacts we are voting on are available here:
> > >
> > > https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.1/rc.2/
> > >
> > > There, you will find a tarball, a GPG signature, and
> > > SHA256/SHA512
> > checksums.
> > >
> > > Please follow the test procedure here:
> > >
> > >
> > https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
> > >
> > > Please remember that "RC2" is an annotation. If the vote
> > > passes,
> > these artefacts will be released as Apache CouchDB 2.3.1.
> > >
> > > Please cast your votes now.
> > >
> > > Thanks,
> > > Jan
> > > —
> > >
> > >> On 17. Feb 2019, at 19:47, Jan Lehnardt 
> > >> wrote:
> > >>
> > >> Dear community,
> > >>
> > >> I would like to propose that we release Apache CouchDB
> > >> 2.3.1-RC1.
> > >>
> > >> Candidate release notes:
> > >>
> > >> https://docs.couchdb.org/en/2.3.1/whatsnew/2.3.html#version-2-3-1
> > >>
> > >> We encourage the whole community to download and test these
> > >> release
> > artefacts so that any critical issues can be resolved before the
> > release is
> > made. Everyone is free to vote on this release, so dig right in!
> > >>
> > >> The release artefacts we are voting on are available here:
> > >>
> > >> https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.1/rc.1/
> > >>
> > >> There, you will find a tarball, a GPG signature, and
> > >> SHA256/SHA512
> > checksums.
> > >>
> > >> Please follow the test procedure here:
> > >>
> > >>
> > https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
> > >>
> > >> Please remember that "RC1" is an annotation. If the vote
> > >> passes,
> > these artefacts will be released as Apache CouchDB 2.3.1.
> > >>
> > >> Please cast your votes now.
> > >>
> > >> Thanks,
> > >> Jan
> > >> —
> > 

Re: [DISCUSS] : things we need to solve/decide : storing JSON documents

[Paul Davis]

Strongly agree that we very much don't want to have Erlang-isms being
pushed into fdb. Regardless of what we end up with I'd like to see a
very strong (de)?serialization layer with some significant test
coverage.

On Tue, Feb 19, 2019 at 6:54 PM Adam Kocoloski  wrote:
>
> Yes, that sort of versioning has been omitted from the various concrete 
> proposals but we definitely want to have it. We’ve seen the alternative in 
> some of the Erlang records that we serialize to disk today and it ain’t 
> pretty.
>
> I can imagine that we’ll want to have the codebase laid out in a way that 
> allows us to upgrade to a smarter KV encoding over time without major 
> surgery, which I think is a good “layer of abstraction”. I would be nervous 
> if we started having abstract containers of data structures pushed down into 
> FDB itself :)
>
> Adam
>
> > On Feb 19, 2019, at 5:41 PM, Paul Davis  wrote:
> >
> > A simple doc storage version number would likely be enough for future us to
> > do fancier things.
> >
> > On Tue, Feb 19, 2019 at 4:16 PM Benjamin Anderson 
> > wrote:
> >
> >>> I don’t think adding a layer of abstraction is the right move just yet,
> >> I think we should continue to find consensus on one answer to this question
> >>
> >> Agree that the theorycrafting stage is not optimal for making
> >> abstraction decisions, but I suspect it would be worthwhile somewhere
> >> between prototyping and releasing. Adam's proposal does seem to me the
> >> most appealing approach on the surface, and I don't see anyone signing
> >> up to do the work to deliver an alternative concurrently.
> >>
> >> --
> >> ba
> >>
> >> On Tue, Feb 19, 2019 at 1:43 PM Robert Samuel Newson 
> >> wrote:
> >>>
> >>> Addendum: By “directory aliasing” I meant within a document (either the
> >> actual Directory thing or something equivalent of our own making). The
> >> directory aliasing for each database is a good way to reduce key size
> >> without a significant cost. Though if Redwood lands in time, even this
> >> would become an inutile obfuscation].
> >>>
>  On 19 Feb 2019, at 21:39, Robert Samuel Newson 
> >> wrote:
> 
>  Interesting suggestion, obviously the details might get the wrong kind
> >> of fun.
> 
>  Somewhere above I suggested this would be something we could change
> >> over time and even use different approaches for different documents within
> >> the same database. This is the long way of saying there are multiple ways
> >> to do this each with advantages and none without disadvantages.
> 
>  I don’t think adding a layer of abstraction is the right move just
> >> yet, I think we should continue to find consensus on one answer to this
> >> question (and the related ones in other threads) for the first release.
> >> It’s easy to say “we can change it later”, of course. We can, though it
> >> would be a chunk of work in the context of something that already works,
> >> I’ve rarely seen anyone sign up for that.
> 
>  I’m fine with the first proposal from Adam, where the keys are tuples
> >> of key parts pointing at terminal values. To make it easier for the first
> >> version, I would exclude optimisations like deduplication or the Directory
> >> aliasing or the schema thing that I suggested and that Ilya incorporated a
> >> variant of in a follow-up post. We’d accept that there are limits on the
> >> sizes of documents, including the awkward-to-express one about property
> >> depth.
> 
>  Stepping back, I’m not seeing any essential improvement over Adam’s
> >> original proposal besides the few corrections and clarifications made by
> >> various authors. Could we start an RFC based on Adam’s original proposal on
> >> document body, revision tree and index storage? We could then have PR’s
> >> against that for each additional optimisation (one person’s optimisation is
> >> another person’s needless complication)?
> 
>  If I’ve missed some genuine advance on the original proposal in this
> >> long thread, please call it out for me.
> 
>  B.
> 
> > On 19 Feb 2019, at 21:15, Benjamin Anderson 
> >> wrote:
> >
> > As is evident by the length of this thread, there's a pretty big
> > design space to cover here, and it seems unlikely we'll have arrived
> > at a "correct" solution even by the time this thing ships. Perhaps it
> > would be worthwhile to treat the in-FDB representation of data as a
> > first-class abstraction and support multiple representations
> > simultaneously?
> >
> > Obviously there's no such thing as a zero-cost abstraction - and I've
> > not thought very hard about how far up the stack the document
> > representation would need to leak - but supporting different layouts
> > (primarily, as Adam points out, on the document body itself) might
> > prove interesting and useful. I'm sure there are folks interested in a
> > column-shaped CouchDB, for example.
> >
> > --
> > b
> >
> 

Re: Re klaemo/couchdb removal

[Jan Lehnardt]

Thanks for the heads up Clemens, feel free to loop in Joel here on the list for 
future discussion. Let’s see if they can get the official repo into an update 
and only look for a contingency plan when that doesn’t work out.

Best
Jan
—

> On 20. Feb 2019, at 08:47, Clemens Stolle  wrote:
> 
> Hey there,
> 
> about a week ago I replaced klaemo/couchdb with an empty image. This was done 
> after discussion with Jan and Joan here: 
> https://github.com/apache/couchdb-docker/issues/133 
> 
> 
> Now, I got an email from npm (see below) telling me that this broke some of 
> their enterprise products. 
> I've already answered them explaining the situation and asking if they could 
> use the official version even if it's one of the unsupported tags of the 1.x 
> series.
> 
> They followed up by saying they'll try to push out updates using the official 
> image:
>> We will continue to work on pushing updates using the official image. 
>> However, if this does not work, perhaps we can revisit this considering an 
>> option which lowers risk while getting some users back on line (such as 
>> publishing the official image under  the tag).
> 
> Any advice on dealing with this situation?
> 
> Cheers,
> Clemens
> 
> Original message:
>> Anfang der weitergeleiteten Nachricht:
>> 
>> Von: Joel Edwards mailto:j...@npmjs.com>>
>> Betreff: Hello from npm
>> Datum: 20. Februar 2019 um 05:31:10 MEZ
>> An: kla...@fastmail.fm 
>> 
>> Good evening Clemens,
>> 
>> My name is Joel Edwards. I work for npm to maintain the public registry and 
>> our enterprise product. About a week ago, the klaemo/couchdb image you 
>> maintain on Docker Hub was replaced with a no-op image. A legacy enterprise 
>> product of ours depends on this image and we now have customers who are 
>> affected by its removal.
>> 
>> We were hoping you might be willing to replace it with a working version in 
>> order to restore operation for those who depend on it (we are likely not the 
>> only ones affected). We were able to duplicate the image and will be pushing 
>> it out to as many customers as we can soon. However, having this restored 
>> would be beneficial either as a stop-gap would be much appreciated.
>> 
>> Please let me know your thoughts and/or concerns if you are concerned about 
>> my request.
>> 
>> Thank you for your consideration.
>> 
>> Best regards,
>> Joel
> 

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/