Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.221.112 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=LBy6vrSuoWKhkL0VbTIhu3lY1V3vOC8naTh0Ox7TTc5ctEHCzE3oPrKXZlpK8EUwAm
         1DZvyr9A3lLhyc2g5bWDvB5zV/A98jaNMdZH1yiCq40G5ABeTowp1V5AKuS9hCBSVcU5
         LpZYD3YENMlUr359uNOGvulmarbOsEdG0DMak=
Sender: Adam Kocoloski <adam.kocoloski@gmail.com>
Message-Id: <2BC6AA55-53D2-404D-BBF8-D9B7218F9D05@apache.org>
From: Adam Kocoloski <kocolosk@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <64F970DF-B005-4076-BE63-7362EE31679D@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Release 0.9.1
Date: Wed, 13 May 2009 10:05:08 -0400
References: <e282921e0905041832j40bcf06ax1476d97cd81df71f@mail.gmail.com>
 <265DE325-6C9D-406A-BFDD-0D5CB7D4BAAA@gmail.com>
 <5FA292E9-7EB1-4F77-BCC8-9C094E5CB102@apache.org>
 <64F970DF-B005-4076-BE63-7362EE31679D@apache.org>

Hi Jan, thanks for doing this.  I believe all of my commits in the  
changeset you listed below are good candidates for merging to 0.9.x.   
I could use a little help with the svn incantations, though -- I  
thought I already merged r765364 into 0.9.x:

http://svn.apache.org/viewvc?view=rev&revision=765387

Do you know what I did wrong?  Cheers, Adam

On May 13, 2009, at 9:42 AM, Jan Lehnardt wrote:

> Hi,
>
> I went through the list* of eligible change sets for the 0.9.x
> branch to get closer to the 0.9.1 release.
>
> I blocked or merged all of my commits, and all new stuff
> from Damien, Chris, Adam, Paul and Noah. I'm sorry if
> I stomped on anyone's feet here, but I figured I might as
> well go through the whole list while I'm in there.
>
> I blocked anything that has remotely to do with "new"
> or "refactor" and only merged a few fixes.
>
> We still do have some eligible change sets open and I
> do believe all of them should be merged into 0.9.x, but
> I don't feel qualified enough to comment on the stability.
>
> These change set are:
> ------------------------------------------------------------------------
> r758093 | damien | 2009-03-25 00:48:33 +0100 (Wed, 25 Mar 2009) | 1  
> line
>
> Fix for crash when compacting an empty database
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> r763858 | damien | 2009-04-10 04:21:37 +0200 (Fri, 10 Apr 2009) | 1  
> line
>
> Fixes for leaked file handles, with test.
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> r765364 | kocolosk | 2009-04-15 23:21:23 +0200 (Wed, 15 Apr 2009) |  
> 2 lines
>
> URL-encode attachment paths during replication
>
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> r766338 | nslater | 2009-04-18 17:20:00 +0200 (Sat, 18 Apr 2009) | 1  
> line
>
> create /var/run/couchdb during init script
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> r766883 | damien | 2009-04-20 23:34:46 +0200 (Mon, 20 Apr 2009) | 1  
> line
>
> Fix for process leaks with retrying compactions.
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> r771474 | kocolosk | 2009-05-05 00:25:23 +0200 (Tue, 05 May 2009) |  
> 2 lines
>
> standalone attachment GETs should respect "rev" qs param
>
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> r771480 | kocolosk | 2009-05-05 00:36:46 +0200 (Tue, 05 May 2009) |  
> 2 lines
>
> use revisions when replicating attachments.  Closes COUCHDB-337
>
> ------------------------------------------------------------------------
>
> Adam, Damien, Noah: Can you comment on your changes
> and whether they should go into the 0.9.x branch?
>
> When we're through with these, I believe we're ready to start
> the 0.9.1 release.
>
> --
>
> Finally, and I'm the first to follow, it'd be great if we all could
> get into the habit of either merging or blocking commits to
> trunk for the 0.9.x branch.
>
> As a reminder.
>
> Blocking REVISION:
>
>  svn merge -c REVISION --record-only trunk branches/0.9.x
>  svn commit branches/Y.Y.x -m "blocked REVISION from trunk"
>
> Merging REVISION:
>
>  svn merge -c REVISION trunk branches/0.9.x
>  svn commit branches/Y.Y.x -m "merged REVISION from trunk"
>
>
> Cheers
> Jan
> --
> * for i in `svn mergeinfo trunk branches/0.9.x --show-revs  
> eligible`; do
>      svn log -r $i;
>  done
>
>
>
> On 6 May 2009, at 19:38, Damien Katz wrote:
>
>>
>> On May 5, 2009, at 9:12 AM, Adam Kocoloski wrote:
>>
>>> On May 4, 2009, at 9:32 PM, Chris Anderson wrote:
>>>
>>>> Devs,
>>>>
>>>> Are we ready for 0.9.1? My pet patch is in and backported, how  
>>>> about yours?
>>>
>>> I wonder if we should try to shore up the JIRA records of what's  
>>> in 0.9.1.  Currently I see
>>>
>>> COUCHDB-306 Wacky error responses to malformed documents
>>> COUCHDB-310 Fix hardcoded redirect to "/_utils/"
>>> COUCHDB-311 Wrong encoded _external error message
>>> COUCHDB-322 Specifying reduce=true on a view with no reduce does  
>>> not cause an error.
>>> COUCHDB-334 With deferred commits and 100+ active dbs, CouchDB can  
>>> lose uncommitted changes
>>> COUCHDB-342 url-encode attachment paths during replication
>>>
>>> as well as one open ticket targeted for 0.9.1:
>>>
>>> COUCHDB-328 [patch] allow futon reduce textareas to contain  
>>> accidental white spaces.
>>>
>>> I'm sure there are other resolved/closed tickets missing from that  
>>> list.  As far as my work is concerned, I think
>>>
>>> COUCHDB-337 attachments from old/conflict revisions are not  
>>> accessible via standalone API
>>>
>>> would be a decent candidate for backporting.  It's a simple fix,  
>>> but the fact that we ran like that for months without anyone  
>>> noticing probably means it's low priority.  Cheers,
>>
>> I think the fix is an important one. The big problem isn't the  
>> failures, it's when it doesn't error out that's the problem. It can  
>> put the wrong attachment data into another revision, which is a  
>> form of data corruption.
>>
>>>
>>> Adam
>>>
>>>
>>>
>>>
>>>
>>
>>
>