My ability to respond is low right now due to being on holiday but am psyched to see plans forming.
One task worth a day of someone's time is to check that the news/changes file includes description of every fix since 1.2. Should be pretty good but probably isn't complete. I recall an important fix to ssl support, for example, which I may not have written up well. Tying every single fix or feature to a Jira ticket will be great too. Sent from the ocean floor On 4 Oct 2012, at 12:35, Noah Slater <[email protected]> wrote: > Thanks! > > Basically, after we ship 1.3, I want to set up a release cadence and create > a 1.4 release branch, and only allow things into it that follow a merge > procedure. > > Take a look at these: > > http://wiki.apache.org/couchdb/Roadmap_Process > > http://wiki.apache.org/couchdb/Merge_Procedure > > There are a few @@ notes I put on there for Bob. Perhaps you can take a > look? > > If you wanna help me get something like this set up, that's awesome! > > On Thu, Oct 4, 2012 at 11:51 AM, Octavian Damiean <[email protected]>wrote: > >> I can recommend "Version Control with Git" from O'Reilly (ISBN-13: >> 978-1449316389). >> >> If Paul or Bob are not reachable for some reason don't hesitate to contact >> me too. :) >> >> On Thu, Oct 4, 2012 at 12:43 PM, Noah Slater <[email protected]> wrote: >> >>> I am full time on Apache at the moment, split between CouchDB docs and >>> CloudStack. Agree with everything I've seen in this thread, especially >> the >>> scope of what's included in 1.3. >>> >>> I have one thing to add. I think, after this release, we should adopt the >>> release cadence and merge procedure that we came up with in Dublin, that >>> has been proposed to the list before. (This ties into Bob's suggestion to >>> use 1.3 as the stable base on which to start merging in all the forks.) >>> It's not really had much discussion since then. Only problem is that I >> need >>> someone to lend a hand with the Git side of things. So I'm looking for >>> someone to join me in some release team activity to get things properly >> set >>> up and communicated out to the community. (Looking at you Paul, Bob. One >> of >>> you, don't need both.) >>> >>> So, who wants to buddy up with me to get this done, post-1.3? Don't all >>> step forward at once. >>> >>> (I'm planning to buy a book on Git. I'm fed up of being so clueless...) >>> >>> On Thu, Oct 4, 2012 at 3:53 AM, Benoit Chesneau <[email protected]> >>> wrote: >>> >>>> On Oct 3, 2012 10:48 PM, "Dave Cottlehuber" <[email protected]> wrote: >>>>> >>>>> On 3 October 2012 21:41, Paul Davis <[email protected]> >>> wrote: >>>>> >>>>>> Only other thing I'd add is that we talked about importing Jiffy. >>>>> >>>>> Good, I'd be up for that. Um did you find (in cloudant land) that it >>>>> handled parsing large docs better? The current ejson struggles >>>>> sometimes I think. Better would mean without spitting the dummy >>>>> completely. >>>>> >>>>> A+ >>>>> Dave >>>> We arw using jiffy in rcouch. It solves some errors too. It is also >>> faster >>>> on large docs, On thing I'm not sure with using a nif here is how it >>>> behaves with dbs containing obky relatively larges docs? If it blocks >> the >>>> scheduling too much or not. >>>> >>>> Maybe cloudant can answer here? >>>> >>>> benoît >>>> >>> >>> >>> >>> -- >>> NS >>> >> > > > > -- > NS
