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/ >
