On 13 Apr 2009, at 22:23, Chris Anderson wrote:
On Mon, Apr 13, 2009 at 2:17 PM, Jan Lehnardt <[email protected]> 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 <[email protected]>
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
