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
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
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
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
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
>
: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:
>>>
>>> *
*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
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.
(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
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
/_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
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
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
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
(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
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
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
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
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
> *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
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
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
>>>>
>>>> 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
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
>> &
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.
> >>
>
+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
+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.
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
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
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.
>
>
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
>&
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
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
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
>>>
>>> -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
-
>>> 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
>>>
>>>
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
+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
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
+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
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
41 matches
Mail list logo