For 2991, removing the ability to rename that db gets my +1. It, like _replicator, should be the same everywhere. It's only configurable so the test suite can use different (random) ones for each test.
Sent from my iPhone > On 26 May 2016, at 21:44, Paul Davis <[email protected]> wrote: > > Derp! Thanks for the heads up. I'll try and take a crack at some of > those issues tomorrow and next week. Monday is a holiday so I probably > wont be around then. > >> On Thu, May 26, 2016 at 4:01 PM, Jan Lehnardt <[email protected]> wrote: >> https://issues.apache.org/jira/browse/COUCHDB-2632?jql=project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC >> — via http://s.apache.org/couchdb-2.0 (from #couchdb-dev on IRC). >> >> >> I’ve started work on https://issues.apache.org/jira/browse/COUCHDB-2991 and >> Sebastian Rothbucher continued it a little further (links in the ticket). >> Since its security related, I don’t want to punt this as “known issues”. >> Sorry it involves the JS tests, but they do encode that part of the >> behaviour pretty well and Cloudant tests don’t seem to cover this, as this >> came in post-BigCouch-merge. >> >> I’m off this Friday and weekend, but might be able to reply to mails. >> Otherwise I’m back on Monday and will try and help get this over the hump. >> >> Best >> Jan >> -- >> >> >> >>> On 26 May 2016, at 22:23, Paul Davis <[email protected]> wrote: >>> >>> Can someone remind me where the list of 2.0 blockers is? >>> >>>> On Thu, May 26, 2016 at 3:17 PM, Joan Touzet <[email protected]> wrote: >>>> Also +1, except for the work to get the Windows port running correctly. >>>> >>>> -Joan >>>> >>>> ----- Original Message ----- >>>>> From: "Michelle Phung" <[email protected]> >>>>> To: [email protected] >>>>> Sent: Thursday, May 26, 2016 7:23:46 AM >>>>> Subject: Re: 2.0 Code Freeze or branching 2.1? >>>>> >>>>> +1 >>>>> >>>>> - Michelle >>>>> >>>>>> On May 26, 2016, at 6:34 AM, Alexander Shorin <[email protected]> >>>>>> 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 >>>>>>> <[email protected]> wrote: >>>>>>> +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 only. >>>>>>> >>>>>>> Lets explicitly say that we'll take no work for future >>>>>>> enhancements or fixes until 2.0 ships. We must get this out. >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On 26 May 2016, at 09:10, Andy Wenk <[email protected]> wrote: >>>>>>>> >>>>>>>> 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 though, that some >>>>>>>> people will work on their own repos. >>>>>>>> >>>>>>>> +1 for code freeze >>>>>>>> >>>>>>>> Side note: as I am not actively developing, my opinion should be >>>>>>>> taken with low prio because there might be reasons from others >>>>>>>> to prefer branching. >>>>>>>> >>>>>>>> Thanks to everyone making CouchDB 2.0 great! >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> -- >>>>>>>> Andy Wenk >>>>>>>> RockIt! >>>>>>>> >>>>>>>> Hamburg / Germany >>>>>>>> >>>>>>>> GPG public key: >>>>>>>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D >>>>>>>> >>>>>>>>> On 26 May 2016, at 09:42, Jan Lehnardt <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> last night on IRC Bob brought up a good point: we have ongoing >>>>>>>>> development going into our repos while we are trying to get 2.0 >>>>>>>>> out the >>>>>>>>> door. It might be time to split these two. >>>>>>>>> >>>>>>>>> Bob suggested a code freeze until we ship a first 2.0 beta. An >>>>>>>>> alternative would be to branch out 2.x.x and stabilise that, >>>>>>>>> port any >>>>>>>>> fixes to master, where regular development can occur there. >>>>>>>>> >>>>>>>>> Both alternatives have their pros and cons, but I like the >>>>>>>>> aspect of a >>>>>>>>> code freeze that forces everyone to help get the release build >>>>>>>>> stable. >>>>>>>>> >>>>>>>>> That said, I fear that most folks would then just commit to >>>>>>>>> their >>>>>>>>> personal or other corporate repos (hello Cloudant) and only sync >>>>>>>>> to ASF >>>>>>>>> repos when the freeze is over, and not help out with the build. >>>>>>>>> >>>>>>>>> E.g. I don’t want to force anyone into anything they don’t want >>>>>>>>> to do >>>>>>>>> with an arbitrary policy, but I’d be in support of a code freeze >>>>>>>>> if >>>>>>>>> people here would signal that it’d help them focus on a stable >>>>>>>>> build >>>>>>>>> as opposed to new feature development. >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Best >>>>>>>>> Jan >>>>>>>>> -- >> >> -- >> Professional Support for Apache CouchDB: >> https://neighbourhood.ie/couchdb-support/ >>
