Re: post 2.1 - gitlab or github

Hello "support-tiger", > As more of newer / outsider couch/pouch users, have to say that Gitlab > (which we really like) or Github seem to offer much more in terms of > descriptions of commits, issues, easier pull request management, ... > Idea is to make easier / incentives for

Re: post 2.1 - gitlab or github

agree and a lot of the work that went into 2.1 is allowing us to make more stable releases faster. That said, in a world of JavaScript Framework of the Week, we’re a database and that means we have to do things at a different pace. CouchDB is responsible for many magnitudes of terabytes of da

post 2.1 - gitlab or github

As more of newer / outsider couch/pouch users, have to say that Gitlab (which we really like) or Github seem to offer much more in terms of descriptions of commits, issues, easier pull request management, ... one year between releases seems much too long - maybe okay for a production

2.1 Bug Review IRC meeting minutes

p> I think I see it 11:28 <+Wohali> oh? 11:28 <+davisp> We're checking the local port and not the clustered port in ensure_all_nodes_alive 11:28 <+Wohali> ahh 11:29 <+davisp> and couch_httpd comes up before chttpd 11:29 <+Wohali> local port comes up first, right 1

Re: [PROPOSAL] Include replication scheduler in 2.1

Hi all, > >>> > >>> *Per the CouchDB bylaws, this is a concrete proposal that will default > >>> to lazy consensus in 72 hours (2017.07.19 ~21:00).* > >>> > >>> As we approach release candidates for v2.1 (see next email), we have > one >

Re: [PROPOSAL] Include replication scheduler in 2.1

:00).* >>> >>> As we approach release candidates for v2.1 (see next email), we have one >>> major decision left to make: whether or not to include the scheduling >>> replicator in 2.1. >>> >>> Arguments for inclusion: >>> >>> *

Re: [PROPOSAL] Include replication scheduler in 2.1

*Per the CouchDB bylaws, this is a concrete proposal that will default >> to lazy consensus in 72 hours (2017.07.19 ~21:00).* >> >> As we approach release candidates for v2.1 (see next email), we have one >> major decision left to make: whether or not to include the schedul

Re: [PROPOSAL] Include replication scheduler in 2.1

e next email), we have one > major decision left to make: whether or not to include the scheduling > replicator in 2.1. > > Arguments for inclusion: > > * New feature allowing CouchDB to manage more replication jobs at > the same time by switching between them / starting / stopping.

Re: [PROPOSAL] Include replication scheduler in 2.1

(see next email), we have one > major decision left to make: whether or not to include the scheduling > replicator in 2.1. > > Arguments for inclusion: > > * New feature allowing CouchDB to manage more replication jobs at > the same time by switching between them / starting

[PROPOSAL] Include replication scheduler in 2.1

Hi all, *Per the CouchDB bylaws, this is a concrete proposal that will default to lazy consensus in 72 hours (2017.07.19 ~21:00).* As we approach release candidates for v2.1 (see next email), we have one major decision left to make: whether or not to include the scheduling replicator in 2.1

Re: [PROPOSAL] Getting 2.1 out the door (was: Test Suite Stabilization)

/_cluster_setup enhancement * require server admin for db/view compaction * 1 is removing a dead feature (broken OAuth 1.0 support) * 11 are test suite failures * 1 is Windows-specific * 1 relates to efforts to automate package building, which may not happen prior to 2.1's release Developers, we could sure

Re: [PROPOSAL] Getting 2.1 out the door (was: Test Suite Stabilization)

On replication scheduler, I think we should stick to the plan and keep it out of 2.1. I'm so happy to hear there's lots of interest in it, though. The main part of getting 2.1 out is all this work to fix tests and release pipeline, so a 2.2 with the scheduler should follow swiftly behind 2.1

[PROPOSAL] Getting 2.1 out the door (was: Test Suite Stabilization)

final point is whether or not we include the replicator scheduler in the 2.1 release. Right now, 2.1 is forked prior to that change. I know the feature's received a lot of interest from the user base, but I worry about this relatively untested code being included. Has Cloudant done more extensive

Re: 2.1

there often helps find/correct the bugs - just call it 2.1 beta - keep up the great work and keep moving forward. On 05/21/2017 03:03 PM, Eli Stevens (Gmail) wrote: (I should note that since I'm the point person for CouchDB at my company, I end up using I/we a bit interchangeably.) On Sun, May

Re: 2.1

(I should note that since I'm the point person for CouchDB at my company, I end up using I/we a bit interchangeably.) On Sun, May 21, 2017 at 3:07 AM, Jan Lehnardt wrote: >> On 21. May 2017, at 04:17, Eli Stevens (Gmail) wrote: >> >> I realize that this

Re: 2.1

Gmail)" > <wickedg...@gmail.com> wrote: >> Please take this as a single data point from an end user: >> >> This approach will probably result in my company declining to upgrade >> to CouchDB 2.1, and instead waiting for 2.2 in hopes that the test >> sui

Re: 2.1

a point from an end user: > >This approach will probably result in my company declining to upgrade >to CouchDB 2.1, and instead waiting for 2.2 in hopes that the test >suite will be in a more stable state by then. This is somewhat ironic, >given that my company is also sponsoring

Re: 2.1

Thanks Eli, good perspective, thanks for sharing! > On 21. May 2017, at 04:17, Eli Stevens (Gmail) <wickedg...@gmail.com> wrote: > > Please take this as a single data point from an end user: > > This approach will probably result in my company declining to upgrade > to

Re: 2.1

Please take this as a single data point from an end user: This approach will probably result in my company declining to upgrade to CouchDB 2.1, and instead waiting for 2.2 in hopes that the test suite will be in a more stable state by then. This is somewhat ironic, given that my company is also

Re: 2.1

> *just* for the 2.1 branch Absolutely, just for that branch, master will keep all failing tests until we sort them out proper. Thanks Paul for elaborating here, that’s precisely my thinking as well. Joan, thanks for highlighting that “just disabling all failing tests” won’t do (e.g. in c

Re: 2.1

Joan, Reading this while on ops but my understanding was that the disabling was *just* for the 2.1 branch. Other than that I agree 100%. Other than wondering why you haven't merged the log upload :P Thats aweome and I agree will help significantly. And I agree that the tests aren't necessarily

Re: 2.1

Hi everyone, I'm +/-0 on this only because there's a little ambiguity in steps 2 and 4 I'd like to clear up. This email is part test status report and part clarification, so I apologize in advance for the length. It is absolutely _almost_ time we get 2.1 out the door. Step 2 is the equivalent

Re: 2.1

>>>> >>>> On Thu, May 11, 2017 at 1:41 PM, Jan Lehnardt <j...@apache.org> wrote: >>>> >>>>> Hi all, >>>>> >>>>> we should get CouchDB 2.1 out soon and the test suite situation is a >>>>> somewhat

Re: 2.1

e: >> > >> > +1 >> > >> > On Thu, May 11, 2017 at 1:41 PM, Jan Lehnardt <j...@apache.org> wrote: >> > >> >> Hi all, >> >> >> >> we should get CouchDB 2.1 out soon and the test suite situation is a >> &

Re: 2.1

rg> wrote: > > > >> Hi all, > >> > >> we should get CouchDB 2.1 out soon and the test suite situation is a > >> somewhat annoying blocker, so I’m proposing something that might sound > >> unusual: disable the failing tests. > >> >

Re: 2.1

+1 > On 11 May 2017, at 18:47, Nick Vatamaniuc <vatam...@gmail.com> wrote: > > +1 > > On Thu, May 11, 2017 at 1:41 PM, Jan Lehnardt <j...@apache.org> wrote: > >> Hi all, >> >> we should get CouchDB 2.1 out soon and the test suite situation is

Re: 2.1

+1 On Thu, May 11, 2017 at 1:41 PM, Jan Lehnardt <j...@apache.org> wrote: > Hi all, > > we should get CouchDB 2.1 out soon and the test suite situation is a > somewhat annoying blocker, so I’m proposing something that might sound > unusual: disable the failing tests.

2.1

Hi all, we should get CouchDB 2.1 out soon and the test suite situation is a somewhat annoying blocker, so I’m proposing something that might sound unusual: disable the failing tests. All test failures are intermittent and we must absolutely address this, but since nobody picked this up since

Re: [PLANNING] CouchDB 2.1

the waters regarding a CouchDB 2.1 release. Since 2.0 > a few new features and many bug fixes have landed. > > I know its holiday season soon and I wanted to kick off the discussion > about a release date for 2.0.1 or 2.1.0. > > One thing that worries me (correct me if I am wrong): I

Re: [PLANNING] CouchDB 2.1

Hi Robert, thanks for taking the lead on this. > On 16 Dec 2016, at 19:55, Robert Kowalski <r...@kowalski.gd> wrote: > > Hi, > > I wanted to test the waters regarding a CouchDB 2.1 release. Since 2.0 > a few new features and many bug fixes have landed. > >

Re: [PLANNING] CouchDB 2.1

SOAP API [ugh]). We also need to manually say "this is the one" > after the lists have gone through acceptance testing. > > -Joan > > - Original Message - >> From: "Robert Kowalski" <r...@kowalski.gd> >> To: dev@couchdb.apache.org >&

Re: [PLANNING] CouchDB 2.1

uot; after the lists have gone through acceptance testing. -Joan - Original Message - > From: "Robert Kowalski" <r...@kowalski.gd> > To: dev@couchdb.apache.org > Sent: Friday, December 16, 2016 1:55:45 PM > Subject: [PLANNING] CouchDB 2.1 > > Hi, > > I

[PLANNING] CouchDB 2.1

Hi, I wanted to test the waters regarding a CouchDB 2.1 release. Since 2.0 a few new features and many bug fixes have landed. I know its holiday season soon and I wanted to kick off the discussion about a release date for 2.0.1 or 2.1.0. One thing that worries me (correct me if I am wrong): I

Re: 2.0 Code Freeze or branching 2.1?

016 at 3:17 PM, Joan Touzet <woh...@apache.org> wrote: >>>> Also +1, except for the work to get the Windows port running correctly. >>>> >>>> -Joan >>>> >>>> - Original Message - >>>>> From: "Michelle

Re: 2.0 Code Freeze or branching 2.1?

>>> >>> -Joan >>> >>> - Original Message - >>>> From: "Michelle Phung" <michelleph...@gmail.com> >>>> To: dev@couchdb.apache.org >>>> Sent: Thursday, May 26, 2016 7:23:46 AM >>>> Subject: Re: 2.0 Code Free

Re: 2.0 Code Freeze or branching 2.1?

- >>> From: "Michelle Phung" <michelleph...@gmail.com> >>> To: dev@couchdb.apache.org >>> Sent: Thursday, May 26, 2016 7:23:46 AM >>> Subject: Re: 2.0 Code Freeze or branching 2.1? >>> >>> +1 >>> >>>

Re: 2.0 Code Freeze or branching 2.1?

Also +1, except for the work to get the Windows port running correctly. -Joan - Original Message - > From: "Michelle Phung" <michelleph...@gmail.com> > To: dev@couchdb.apache.org > Sent: Thursday, May 26, 2016 7:23:46 AM > Subject: Re: 2.0 Code Free

Re: 2.0 Code Freeze or branching 2.1?

+1 - Michelle > On May 26, 2016, at 6:34 AM, Alexander Shorin wrote: > > I think that's better call feature/improvements freeze, since we still > have to commit the code that includes bugfixes. > > +1 > -- > ,,,^..^,,, > > >> On Thu, May 26, 2016 at 12:56 PM, Robert Newson

Re: 2.0 Code Freeze or branching 2.1?

I think that's better call feature/improvements freeze, since we still have to commit the code that includes bugfixes. +1 -- ,,,^..^,,, On Thu, May 26, 2016 at 12:56 PM, Robert Newson wrote: > +1 for code freeze. > > The only changes we will merge to master branches must

Re: 2.0 Code Freeze or branching 2.1?

+1 for code freeze. The only changes we will merge to master branches must contribute toward 2.0 actually shipping. I would also not make 2.x.x branches until 2.0 is GA. the first commit on all those branches should be the release itself. Subsequent commits are backported fixes from master

Re: 2.0 Code Freeze or branching 2.1?

Hi, in my opinion, everybody is interested to add new features on a stable version of CouchDB. So with a code freeze, everybody is asked to help get 2.0 shipped because then, new features can be added with more focus and on a stable release. For me, this sounds better than branching even