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