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 <paul.joseph.da...@gmail.com> wrote: > > Can someone remind me where the list of 2.0 blockers is? > > On Thu, May 26, 2016 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 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 >>> >>> - Michelle >>> >>>> On May 26, 2016, at 6:34 AM, Alexander Shorin <kxe...@gmail.com> >>>> 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 >>>>> <rnew...@apache.org> 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 <andyw...@apache.org> 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 <j...@apache.org> 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/
