Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <9C954994-8C8A-4E49-A879-596BF75B7210@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <e282921e0904131423l3707b36agb9a6dba8b064ed19@mail.gmail.com>
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: Backporting bug fixes to 0.9
Date: Mon, 13 Apr 2009 23:41:52 +0100
References: <01EF20DF-3782-4FDA-B90A-D814636F1F8F@apache.org>
 <e2111bbb0904131145hf302a13t3bb79c9c4bf72338@mail.gmail.com>
 <BC777F64-1811-4854-BBEF-8264985E04AB@apache.org>
 <e282921e0904131423l3707b36agb9a6dba8b064ed19@mail.gmail.com>


On 13 Apr 2009, at 22:23, Chris Anderson wrote:

> On Mon, Apr 13, 2009 at 2:17 PM, Jan Lehnardt <jan@apache.org> wrote:
>>
>> On 13 Apr 2009, at 19:45, Paul Davis wrote:
>>
>>> Is there a reason to not just take current trunk and tag it as  
>>> 0.9.1?
>>> I'd be +1 for making some sort of release tarball with Jan's listed
>>> commits.
>>
>> I'm not proposing cutting a release just yet, just making sure we
>> define which commits go into the 0.9.x tree. I'd -1 using trunk to
>> cut 0.9.1; just for good practice. We do have the 0.9.x branch
>> and with the practice of "backporting" we make sure that we
>> don't step on each other in two branches and accidentally
>> commit stuff to the "stable" branch that is only meant for
>> "unstable" trunk. Right now it seems overkill but past
>> experience has shown that this is a good practice to keep
>> up.
>>
>> I'd rather examine each commit then just cutting from trunk
>> now. For example:
>>
>> refactor: extract method from doc_flush_binaries. add with_stream/2  
>> to
>> handle automatically opening and closing binary streams:
>> http://svn.apache.org/viewvc?rev=764257&view=rev seems a good
>> candidate to not go into 0.9.1
>>
>
> Maybe... I'd argue it can go in as it doesn't change behavior, just
> makes the code a little more readable. But then again, maybe I
> introduced a bug (hope not)...
>
> Anyway, there are a few non-0.9 commits, so now that I read the log I
> think cherry picking is in order.

One (not yet clearly expressed) desired result of this thread is also to
raise awareness for committers to evaluate, on commit, if a patch
needs to go into any branch beside trunk, to avoid cherry-picking
which might oversee things.

(yeah, yadda, yadda, process over people and all, but doing things
later usually means doing things never, os a little process can help :)

So yeah, start the cherry picking for the last six or so weeks and
for new commits decide right away if it needs to go into a branch
as well.

Cheers
Jan
--


>
>>
>> Cheers
>> Jan
>> --
>>
>>
>>>
>>> On Mon, Apr 13, 2009 at 2:41 PM, Jan Lehnardt <jan@apache.org>  
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> as I understand trunk is now effectively 0.10-dev. Do we want to
>>>> maintain the 0.9.x branch and backport some of the bug fixes that
>>>> go into trunk? (I'd say yes we do.)
>>>>
>>>> If yes, I'd like to propose the following commits to be backported:
>>>>
>>>> Fixes for leaked file handles, with test:
>>>> http://svn.apache.org/viewvc?rev=763858&view=rev
>>>> (not sure if it is possible with the other changes near that  
>>>> commit)
>>>>
>>>> Fix for attachment sparseness bug COUCHDB-220 by giving each  
>>>> attachment
>>>> it's
>>>> own stream and calling set_min_buffer instead of ensure_buffer.  
>>>> Also
>>>> fixed
>>>> spurious couch_file crash messages by putting the statistics  
>>>> decrement
>>>> code
>>>> into a seperate monitoring process:
>>>> http://svn.apache.org/viewvc?rev=763816&view=rev
>>>> (Again, not sure, if it is really possible)
>>>>
>>>> Use now_diff instead of statistics(runtime). Closes COUCHDB-316:
>>>> http://svn.apache.org/viewvc?rev=762019&view=rev
>>>> (Should be simple)
>>>>
>>>> And all updates to the README that are not 0.10 specific:
>>>> http://svn.apache.org/viewvc?rev=761352&view=rev
>>>> http://svn.apache.org/viewvc?rev=761343&view=rev
>>>> http://svn.apache.org/viewvc?rev=760538&view=rev
>>>> http://svn.apache.org/viewvc?rev=760537&view=rev
>>>>
>>>> And I believe Noah had at least one fix for the build
>>>> system, but I don't know which one. Noah?
>>>>
>>>>
>>>> Any commits I missed?
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> Cheers
>>>> Jan
>>>> --
>>>>
>>>>
>>>
>>
>>
>
>
>
> -- 
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>