You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Damien Katz <da...@apache.org> on 2010/06/03 22:59:56 UTC
New code goes into trunk
When developing code and fixes for the 0.11.x branch, it should be first checked into trunk,then merged into 0.11.x branch. Right now I'm dealing as a I merge code from trunk to the branch, I'm dealing with merge conflicts in the attachment encoding code, which should have been in trunk all along.
The only time when code shouldn't go into trunk is when it's doesn't at all apply to trunk, because the code in trunk has already diverged because of post-1.0 feature work.
-Damien
Re: New code goes into trunk
Posted by Jan Lehnardt <ja...@apache.org>.
Thanks all for the reviews!
I applied my monster-fix branch into branches/0.11.x now. Boy do I love me some git :)
Cheers
Jan
--
On 14 Jun 2010, at 00:24, Adam Kocoloski wrote:
> On Jun 13, 2010, at 12:25 PM, Jan Lehnardt wrote:
>
>>
>> On 5 Jun 2010, at 23:45, J Chris Anderson wrote:
>>
>>>
>>> On Jun 5, 2010, at 12:44 PM, Adam Kocoloski wrote:
>>>
>>>> I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
>>>>
>>>
>>> I've been reviewing the diff between trunk and 0.11.x -- I can't find anything that shows up in the diff that shouldn't be in 1.0. I'm happy to recommend that we cut 1.0 from trunk.
>>>
>>> I'd like it if others could repeat the exercise and see if they agree with me. There are some things that cover a lot of code (the couch_util:get_value patch and the base64 changes, for instance) which aren't at risk of creating bugs and will only make it harder to backport to 1.0 if we don't put them in the 1.0 release.
>>>
>>> I don't have much opinion about what should go into 0.11.x from trunk, but that's a different topic.
>>
>> I got it all solved and have 0.11.x merged up all right.
>>
>> In the process I found I had a faulty backport in there.
>>
>> See my work here: http://github.com/janl/couchdb/tree/0.11.x-monster-fix
>>
>> This is mostly reverting and reapplying in correct order patches to trunk into 0.11.x.
>>
>> I'm happy to commit that as soon as I get a green light.
>>
>> While going through all the commits, there are a few more where I agree with Chris that I'd like to backport before branching 1.0 from 0.11.x but I think we should go ahead as planned and branch 1.0.x from 0.11.x.
>>
>> trunk will then be 1.1.x.
>>
>> Go?
>>
>> Cheers
>> Jan
>> --
>
> The 0.11 branch still feels weird to me. I thought commits on release branches were supposed to be bugfixes only. With 0.11.x the criteria seem to be
>
> 1) bugfixes
> 2) anything committed to trunk by Damien
> 3) anything else needed to make 2) merge cleanly
>
> If 1.0 is supposed to be 0.11 + bugfixes + Damien's work, rather than 0.11 + bugfixes, shouldn't we have a /branches/1.0.x for that?
>
> Regardless, the important thing is that the codebase for 1.0 is stable and working. Jan's 0.11.x-monster-fix satisfies that. Good work!
>
> Adam
>
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by till <ti...@php.net>.
I'd like to second COUCHDB-780. :D
On Tue, Jun 15, 2010 at 7:22 PM, Randall Leeds <ra...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/COUCHDB-780 relates to windows file
> issues as well as fixing a source of surprising unresponsiveness with big
> databases (finishing compaction, deleting, etc). This patch is the only one
> I'd really like to wrap up for 1.0.
>
> On Jun 15, 2010 9:16 AM, "Juhani Ränkimies" <ju...@juranki.com> wrote:
>
> On Tue, Jun 15, 2010 at 6:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Which other issues or patches that are not in 0.11.x yet do
>> you think need to be addressed befor...
> Windows file handling problems
> (https://issues.apache.org/jira/browse/COUCHDB-86 and
> https://issues.apache.org/jira/browse/COUCHDB-326)
>
>
> -juhani
>
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
https://issues.apache.org/jira/browse/COUCHDB-780 relates to windows file
issues as well as fixing a source of surprising unresponsiveness with big
databases (finishing compaction, deleting, etc). This patch is the only one
I'd really like to wrap up for 1.0.
On Jun 15, 2010 9:16 AM, "Juhani Ränkimies" <ju...@juranki.com> wrote:
On Tue, Jun 15, 2010 at 6:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed befor...
Windows file handling problems
(https://issues.apache.org/jira/browse/COUCHDB-86 and
https://issues.apache.org/jira/browse/COUCHDB-326)
-juhani
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Juhani Ränkimies <ju...@juranki.com>.
On Tue, Jun 15, 2010 at 6:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed before we branch 1.0? I'd
> like to hear from everybody here, especially the
> non-committers.
>
> Cheers
> Jan
> --
Windows file handling problems
(https://issues.apache.org/jira/browse/COUCHDB-86 and
https://issues.apache.org/jira/browse/COUCHDB-326)
-juhani
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Filipe David Manana <fd...@gmail.com>.
#2 issue of https://issues.apache.org/jira/browse/COUCHDB-793
On Tue, Jun 15, 2010 at 4:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 14 Jun 2010, at 23:18, Jan Lehnardt wrote:
>
> >> To make sure I understand... did we agree to branch 1.0 from trunk?
> >
> > Nope, we agreed to cut 1.0 from 0.11.x. 0.11.x was in disarray for a
> brief time but my latest commits are supposed to have fixed that. I think we
> should go ahead and branch 1.0.x from 0.11.x after applying and merging what
> we believe are the last patches that need to make it into 1,0.0. I should be
> ready with this for my end by tomorrow night CEST.
>
> And done :)
>
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed before we branch 1.0? I'd
> like to hear from everybody here, especially the
> non-committers.
>
> Cheers
> Jan
> --
>
>
--
Filipe David Manana,
fdmanana@gmail.com
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
Glad to have helped!
On 17 Jun 2010, at 18:01, Randall Leeds wrote:
> Oh! So now I feel silly. I'm quite sorry for the noise, Noah. You have found
> the source of my confusion. Somehow I didn't really know the distinction
> between shell variables and environment variables[1]. No wonder I was
> frustrated trying to follow you...
>
> The su man page didn't help with its -m flag. That's what sent me off track.
>
>
> All clear now. Just needed to export it.
>
> [1]
> http://www.fnal.gov/docs/UNIX/unix_at_fermilab/htmldoc/rev1997/uatf-62.html
>
> On Jun 17, 2010 3:43 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
>
>
> On 17 Jun 2010, at 01:57, Randall Leeds wrote:
>
>> Okay. My issue here stems from the fact that I do...
> If you put this:
>
> export ERL_MAX_PORTS=1024
>
> Into this:
>
> /etc/default/couchdb
>
> Then running this:
>
> /etc/init.d/couchdb start
>
> Would pick up the value in the first example, and pass it to Erlang.
>
> So as far as I know, the CouchDB daemon is already configurable in the
> manner you describe. If the above does not work, then it should, and that is
> a bug. If you're not wanting to use the standard init system for CouchDB,
> then you are on your own in terms of setting up the correct environment for
> whatever system you have designed.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
Oh! So now I feel silly. I'm quite sorry for the noise, Noah. You have found
the source of my confusion. Somehow I didn't really know the distinction
between shell variables and environment variables[1]. No wonder I was
frustrated trying to follow you...
The su man page didn't help with its -m flag. That's what sent me off track.
All clear now. Just needed to export it.
[1]
http://www.fnal.gov/docs/UNIX/unix_at_fermilab/htmldoc/rev1997/uatf-62.html
On Jun 17, 2010 3:43 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
On 17 Jun 2010, at 01:57, Randall Leeds wrote:
> Okay. My issue here stems from the fact that I do...
If you put this:
export ERL_MAX_PORTS=1024
Into this:
/etc/default/couchdb
Then running this:
/etc/init.d/couchdb start
Would pick up the value in the first example, and pass it to Erlang.
So as far as I know, the CouchDB daemon is already configurable in the
manner you describe. If the above does not work, then it should, and that is
a bug. If you're not wanting to use the standard init system for CouchDB,
then you are on your own in terms of setting up the correct environment for
whatever system you have designed.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
On 17 Jun 2010, at 01:57, Randall Leeds wrote:
> Okay. My issue here stems from the fact that I don't consider using more
> than 1024 ports a specialist use case deserving of a custom wrapper. Having
> fifty replications with default options already goes beyond this limit.
>
> COUCHDB_OPTIONS could be used for command line flags with the change I
> proposed above, but ERL_MAX_PORTS is only set via the environment, which
> should be easily configured but is currently not.
If you put this:
export ERL_MAX_PORTS=1024
Into this:
/etc/default/couchdb
Then running this:
/etc/init.d/couchdb start
Would pick up the value in the first example, and pass it to Erlang.
So as far as I know, the CouchDB daemon is already configurable in the manner you describe. If the above does not work, then it should, and that is a bug. If you're not wanting to use the standard init system for CouchDB, then you are on your own in terms of setting up the correct environment for whatever system you have designed.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
Okay. My issue here stems from the fact that I don't consider using more
than 1024 ports a specialist use case deserving of a custom wrapper. Having
fifty replications with default options already goes beyond this limit.
COUCHDB_OPTIONS could be used for command line flags with the change I
proposed above, but ERL_MAX_PORTS is only set via the environment, which
should be easily configured but is currently not.
On Jun 16, 2010 5:39 PM, "Noah Slater" <ns...@tumbolia.org> wrote:
On 17 Jun 2010, at 01:07, Randall Leeds wrote:
> On Wed, Jun 16, 2010 at 16:52, Noah Slater <nslat...
-1 on that.
The /etc/defaults/couchdb file is specifically for the init system.
You can pass arbitrary flags to Erlang using the ERL_FLAGS environment
variable. The script takes special care to make sure that Erlang shares its
environment. If you have a specific set of flags you wish to call as
standard, and you don't wish to use the init.d system, then I would advise
that you create a wrapper script for your particular use case.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
On 17 Jun 2010, at 01:07, Randall Leeds wrote:
> On Wed, Jun 16, 2010 at 16:52, Noah Slater <ns...@tumbolia.org> wrote:
>>
>> On 16 Jun 2010, at 23:59, Randall Leeds wrote:
>>
>>> I'd really like to sort out the situation with resource limits.
>>>
>>> My patch to allow setting a larger mochiweb connection limit was
>>> committed (COUCHDB-705), but currently there's no easy user story for
>>> increasing things like ERL_MAX_PORTS. I'd also be nice if we could
>>> allow people to pass arbitrary flags to the vm. For example, I only
>>> recently discovered how nice the +A option is. Unfortunately, the
>>> solution I have in production to avoid clobbering the init script is
>>> to have the couchdb user use bash as a login shell and export
>>> ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
>>> really hackish thing to do to a daemon.
>>
>> Why can't we just use /etc/defaults/couchdb for this?
>
> We can. Currently the init script sources that and passes the relevant
> options directly. I'd be +1 on having the init script call couch much
> more blindly and let /usr/bin/couchdb deal with sourcing the defaults.
> This would obviate the need for passing arguments to erlang because
> ERL_(A|Z)?FLAGS could be used instead.
> I can write this if you don't have time, but your sh-fu is probably
> better than mine.
-1 on that.
The /etc/defaults/couchdb file is specifically for the init system.
You can pass arbitrary flags to Erlang using the ERL_FLAGS environment variable. The script takes special care to make sure that Erlang shares its environment. If you have a specific set of flags you wish to call as standard, and you don't wish to use the init.d system, then I would advise that you create a wrapper script for your particular use case.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Jun 16, 2010 at 16:52, Noah Slater <ns...@tumbolia.org> wrote:
>
> On 16 Jun 2010, at 23:59, Randall Leeds wrote:
>
>> I'd really like to sort out the situation with resource limits.
>>
>> My patch to allow setting a larger mochiweb connection limit was
>> committed (COUCHDB-705), but currently there's no easy user story for
>> increasing things like ERL_MAX_PORTS. I'd also be nice if we could
>> allow people to pass arbitrary flags to the vm. For example, I only
>> recently discovered how nice the +A option is. Unfortunately, the
>> solution I have in production to avoid clobbering the init script is
>> to have the couchdb user use bash as a login shell and export
>> ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
>> really hackish thing to do to a daemon.
>
> Why can't we just use /etc/defaults/couchdb for this?
We can. Currently the init script sources that and passes the relevant
options directly. I'd be +1 on having the init script call couch much
more blindly and let /usr/bin/couchdb deal with sourcing the defaults.
This would obviate the need for passing arguments to erlang because
ERL_(A|Z)?FLAGS could be used instead.
I can write this if you don't have time, but your sh-fu is probably
better than mine.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
On 16 Jun 2010, at 23:59, Randall Leeds wrote:
> I'd really like to sort out the situation with resource limits.
>
> My patch to allow setting a larger mochiweb connection limit was
> committed (COUCHDB-705), but currently there's no easy user story for
> increasing things like ERL_MAX_PORTS. I'd also be nice if we could
> allow people to pass arbitrary flags to the vm. For example, I only
> recently discovered how nice the +A option is. Unfortunately, the
> solution I have in production to avoid clobbering the init script is
> to have the couchdb user use bash as a login shell and export
> ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
> really hackish thing to do to a daemon.
Why can't we just use /etc/defaults/couchdb for this?
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
I'd really like to sort out the situation with resource limits.
My patch to allow setting a larger mochiweb connection limit was
committed (COUCHDB-705), but currently there's no easy user story for
increasing things like ERL_MAX_PORTS. I'd also be nice if we could
allow people to pass arbitrary flags to the vm. For example, I only
recently discovered how nice the +A option is. Unfortunately, the
solution I have in production to avoid clobbering the init script is
to have the couchdb user use bash as a login shell and export
ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
really hackish thing to do to a daemon.
COUCHDB-590 has been sitting idle for quite some time. I recently
discovered /etc/security/limits.conf and so I closed it as invalid and
distro specific. With that taken care of all we really need is
ERL_MAX_PORTS.
rnewson suggested I look at ejabberd. I found that they source
/etc/default/ejabberd in /usr/sbin/ejabberd. Couch doesn't do this,
which I actually sort of like, because it lets you launch couch by
hand without grabbing all those variables.
I'm thinking that anything after a "--" could be passed straight to
erlang, which covers flags like +A <n>. But how should one set an
arbitrary environment for couch? I'd be fine with something like
/etc/couchdb/environment which gets sourced by bin/couchdb.
Thoughts? I think it'd be unfortunate if this story wasn't sorted out
before 1.0.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Zachary Zolton <za...@gmail.com>.
+1 on #802. (I've already been bitten this)
On Wednesday, June 16, 2010, Jason Smith <jh...@couch.io> wrote:
> On Tue, Jun 15, 2010 at 22:22, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Which other issues or patches that are not in 0.11.x yet do
>> you think need to be addressed before we branch 1.0? I'd
>> like to hear from everybody here, especially the
>> non-committers.
>
>
> I would love to see COUCHDB-802 go in. IMO it would be unfortunate to freeze
> the API where a _show and _update are incapable of mimicking the standard
> api (made quite powerful due to vhosts and rewrite).
>
> --
> Jason Smith
> Couchio Hosting
>
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Jason Smith <jh...@couch.io>.
On Tue, Jun 15, 2010 at 22:22, Jan Lehnardt <ja...@apache.org> wrote:
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed before we branch 1.0? I'd
> like to hear from everybody here, especially the
> non-committers.
I would love to see COUCHDB-802 go in. IMO it would be unfortunate to freeze
the API where a _show and _update are incapable of mimicking the standard
api (made quite powerful due to vhosts and rewrite).
--
Jason Smith
Couchio Hosting
Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Jan Lehnardt <ja...@apache.org>.
On 14 Jun 2010, at 23:18, Jan Lehnardt wrote:
>> To make sure I understand... did we agree to branch 1.0 from trunk?
>
> Nope, we agreed to cut 1.0 from 0.11.x. 0.11.x was in disarray for a brief time but my latest commits are supposed to have fixed that. I think we should go ahead and branch 1.0.x from 0.11.x after applying and merging what we believe are the last patches that need to make it into 1,0.0. I should be ready with this for my end by tomorrow night CEST.
And done :)
Which other issues or patches that are not in 0.11.x yet do
you think need to be addressed before we branch 1.0? I'd
like to hear from everybody here, especially the
non-committers.
Cheers
Jan
--
Re: New code goes into trunk
Posted by Jan Lehnardt <ja...@apache.org>.
On 14 Jun 2010, at 19:07, J Chris Anderson wrote:
>
> On Jun 13, 2010, at 3:24 PM, Adam Kocoloski wrote:
>>>
>>
>> The 0.11 branch still feels weird to me. I thought commits on release branches were supposed to be bugfixes only. With 0.11.x the criteria seem to be
>>
>> 1) bugfixes
>> 2) anything committed to trunk by Damien
>> 3) anything else needed to make 2) merge cleanly
>>
>> If 1.0 is supposed to be 0.11 + bugfixes + Damien's work, rather than 0.11 + bugfixes, shouldn't we have a /branches/1.0.x for that?
>>
>
> Agreed -- that's why I suggested branching 1.0.x from trunk. There are a couple of patches I've been working on over the weekend without internet, that I need to put into trunk before we can branch. I will do that today or tomorrow, then I will be ready to branch 1.0.
>
> To make sure I understand... did we agree to branch 1.0 from trunk?
Nope, we agreed to cut 1.0 from 0.11.x. 0.11.x was in disarray for a brief time but my latest commits are supposed to have fixed that. I think we should go ahead and branch 1.0.x from 0.11.x after applying and merging what we believe are the last patches that need to make it into 1,0.0. I should be ready with this for my end by tomorrow night CEST.
(You did propose to cut 1.0.x from trunk last week, but we didn't yet decide on it. Since that was spurred by the merge problems that I fixed now I think we can keep going with the old plan).
Cheers
Jan
--
>
> Chris
>
>> Regardless, the important thing is that the codebase for 1.0 is stable and working. Jan's 0.11.x-monster-fix satisfies that. Good work!
>>
>> Adam
>>
>
Re: New code goes into trunk
Posted by J Chris Anderson <jc...@gmail.com>.
On Jun 13, 2010, at 3:24 PM, Adam Kocoloski wrote:
>>
>
> The 0.11 branch still feels weird to me. I thought commits on release branches were supposed to be bugfixes only. With 0.11.x the criteria seem to be
>
> 1) bugfixes
> 2) anything committed to trunk by Damien
> 3) anything else needed to make 2) merge cleanly
>
> If 1.0 is supposed to be 0.11 + bugfixes + Damien's work, rather than 0.11 + bugfixes, shouldn't we have a /branches/1.0.x for that?
>
Agreed -- that's why I suggested branching 1.0.x from trunk. There are a couple of patches I've been working on over the weekend without internet, that I need to put into trunk before we can branch. I will do that today or tomorrow, then I will be ready to branch 1.0.
To make sure I understand... did we agree to branch 1.0 from trunk?
Chris
> Regardless, the important thing is that the codebase for 1.0 is stable and working. Jan's 0.11.x-monster-fix satisfies that. Good work!
>
> Adam
>
Re: New code goes into trunk
Posted by Adam Kocoloski <ko...@apache.org>.
On Jun 13, 2010, at 12:25 PM, Jan Lehnardt wrote:
>
> On 5 Jun 2010, at 23:45, J Chris Anderson wrote:
>
>>
>> On Jun 5, 2010, at 12:44 PM, Adam Kocoloski wrote:
>>
>>> I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
>>>
>>
>> I've been reviewing the diff between trunk and 0.11.x -- I can't find anything that shows up in the diff that shouldn't be in 1.0. I'm happy to recommend that we cut 1.0 from trunk.
>>
>> I'd like it if others could repeat the exercise and see if they agree with me. There are some things that cover a lot of code (the couch_util:get_value patch and the base64 changes, for instance) which aren't at risk of creating bugs and will only make it harder to backport to 1.0 if we don't put them in the 1.0 release.
>>
>> I don't have much opinion about what should go into 0.11.x from trunk, but that's a different topic.
>
> I got it all solved and have 0.11.x merged up all right.
>
> In the process I found I had a faulty backport in there.
>
> See my work here: http://github.com/janl/couchdb/tree/0.11.x-monster-fix
>
> This is mostly reverting and reapplying in correct order patches to trunk into 0.11.x.
>
> I'm happy to commit that as soon as I get a green light.
>
> While going through all the commits, there are a few more where I agree with Chris that I'd like to backport before branching 1.0 from 0.11.x but I think we should go ahead as planned and branch 1.0.x from 0.11.x.
>
> trunk will then be 1.1.x.
>
> Go?
>
> Cheers
> Jan
> --
The 0.11 branch still feels weird to me. I thought commits on release branches were supposed to be bugfixes only. With 0.11.x the criteria seem to be
1) bugfixes
2) anything committed to trunk by Damien
3) anything else needed to make 2) merge cleanly
If 1.0 is supposed to be 0.11 + bugfixes + Damien's work, rather than 0.11 + bugfixes, shouldn't we have a /branches/1.0.x for that?
Regardless, the important thing is that the codebase for 1.0 is stable and working. Jan's 0.11.x-monster-fix satisfies that. Good work!
Adam
Re: New code goes into trunk
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Jun 13, 2010 at 12:25 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 5 Jun 2010, at 23:45, J Chris Anderson wrote:
>
>>
>> On Jun 5, 2010, at 12:44 PM, Adam Kocoloski wrote:
>>
>>> I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
>>>
>>
>> I've been reviewing the diff between trunk and 0.11.x -- I can't find anything that shows up in the diff that shouldn't be in 1.0. I'm happy to recommend that we cut 1.0 from trunk.
>>
>> I'd like it if others could repeat the exercise and see if they agree with me. There are some things that cover a lot of code (the couch_util:get_value patch and the base64 changes, for instance) which aren't at risk of creating bugs and will only make it harder to backport to 1.0 if we don't put them in the 1.0 release.
>>
>> I don't have much opinion about what should go into 0.11.x from trunk, but that's a different topic.
>
> I got it all solved and have 0.11.x merged up all right.
>
> In the process I found I had a faulty backport in there.
>
> See my work here: http://github.com/janl/couchdb/tree/0.11.x-monster-fix
>
> This is mostly reverting and reapplying in correct order patches to trunk into 0.11.x.
>
> I'm happy to commit that as soon as I get a green light.
>
> While going through all the commits, there are a few more where I agree with Chris that I'd like to backport before branching 1.0 from 0.11.x but I think we should go ahead as planned and branch 1.0.x from 0.11.x.
>
> trunk will then be 1.1.x.
>
> Go?
>
> Cheers
> Jan
> --
>
Patch set looks good to me. Its a 0.11.x fast forward and everything
that was reverted was reapplied.
Good work tracking that down Jan.
Paul
Re: New code goes into trunk
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Jun 13, 2010 at 6:25 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 5 Jun 2010, at 23:45, J Chris Anderson wrote:
>
>>
>> On Jun 5, 2010, at 12:44 PM, Adam Kocoloski wrote:
>>
>>> I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
>>>
>>
>> I've been reviewing the diff between trunk and 0.11.x -- I can't find anything that shows up in the diff that shouldn't be in 1.0. I'm happy to recommend that we cut 1.0 from trunk.
>>
>> I'd like it if others could repeat the exercise and see if they agree with me. There are some things that cover a lot of code (the couch_util:get_value patch and the base64 changes, for instance) which aren't at risk of creating bugs and will only make it harder to backport to 1.0 if we don't put them in the 1.0 release.
>>
>> I don't have much opinion about what should go into 0.11.x from trunk, but that's a different topic.
>
> I got it all solved and have 0.11.x merged up all right.
>
> In the process I found I had a faulty backport in there.
>
> See my work here: http://github.com/janl/couchdb/tree/0.11.x-monster-fix
>
> This is mostly reverting and reapplying in correct order patches to trunk into 0.11.x.
>
> I'm happy to commit that as soon as I get a green light.
>
> While going through all the commits, there are a few more where I agree with Chris that I'd like to backport before branching 1.0 from 0.11.x but I think we should go ahead as planned and branch 1.0.x from 0.11.x.
>
> trunk will then be 1.1.x.
>
> Go?
>
> Cheers
> Jan
> --
>
>
>
>
patch looks ok here. Also tested it irl and all tests where ok.
- benoit
Re: New code goes into trunk
Posted by Jan Lehnardt <ja...@apache.org>.
On 5 Jun 2010, at 23:45, J Chris Anderson wrote:
>
> On Jun 5, 2010, at 12:44 PM, Adam Kocoloski wrote:
>
>> I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
>>
>
> I've been reviewing the diff between trunk and 0.11.x -- I can't find anything that shows up in the diff that shouldn't be in 1.0. I'm happy to recommend that we cut 1.0 from trunk.
>
> I'd like it if others could repeat the exercise and see if they agree with me. There are some things that cover a lot of code (the couch_util:get_value patch and the base64 changes, for instance) which aren't at risk of creating bugs and will only make it harder to backport to 1.0 if we don't put them in the 1.0 release.
>
> I don't have much opinion about what should go into 0.11.x from trunk, but that's a different topic.
I got it all solved and have 0.11.x merged up all right.
In the process I found I had a faulty backport in there.
See my work here: http://github.com/janl/couchdb/tree/0.11.x-monster-fix
This is mostly reverting and reapplying in correct order patches to trunk into 0.11.x.
I'm happy to commit that as soon as I get a green light.
While going through all the commits, there are a few more where I agree with Chris that I'd like to backport before branching 1.0 from 0.11.x but I think we should go ahead as planned and branch 1.0.x from 0.11.x.
trunk will then be 1.1.x.
Go?
Cheers
Jan
--
Re: New code goes into trunk
Posted by J Chris Anderson <jc...@gmail.com>.
On Jun 5, 2010, at 12:44 PM, Adam Kocoloski wrote:
> I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
>
I've been reviewing the diff between trunk and 0.11.x -- I can't find anything that shows up in the diff that shouldn't be in 1.0. I'm happy to recommend that we cut 1.0 from trunk.
I'd like it if others could repeat the exercise and see if they agree with me. There are some things that cover a lot of code (the couch_util:get_value patch and the base64 changes, for instance) which aren't at risk of creating bugs and will only make it harder to backport to 1.0 if we don't put them in the 1.0 release.
I don't have much opinion about what should go into 0.11.x from trunk, but that's a different topic.
Chris
Re: New code goes into trunk
Posted by Adam Kocoloski <ko...@apache.org>.
I've only been merging bugfixes into 0.11.x for a long time now. I think I committed a number of things into trunk related to JIRA tickets with a Fix Version of 1.1.
On Jun 3, 2010, at 6:41 PM, Damien Katz wrote:
> I was wrong, the problem I'm facing are previous commits that weren't merged into 0.11.x branch.
>
> Does anyone know of any commits that _shouldn't_ be merged from trunk to 0.11.x?
>
> -Damien
>
> On Jun 3, 2010, at 1:59 PM, Damien Katz wrote:
>
>> When developing code and fixes for the 0.11.x branch, it should be first checked into trunk,then merged into 0.11.x branch. Right now I'm dealing as a I merge code from trunk to the branch, I'm dealing with merge conflicts in the attachment encoding code, which should have been in trunk all along.
>>
>> The only time when code shouldn't go into trunk is when it's doesn't at all apply to trunk, because the code in trunk has already diverged because of post-1.0 feature work.
>>
>> -Damien
>
Re: New code goes into trunk
Posted by Damien Katz <da...@apache.org>.
I was wrong, the problem I'm facing are previous commits that weren't merged into 0.11.x branch.
Does anyone know of any commits that _shouldn't_ be merged from trunk to 0.11.x?
-Damien
On Jun 3, 2010, at 1:59 PM, Damien Katz wrote:
> When developing code and fixes for the 0.11.x branch, it should be first checked into trunk,then merged into 0.11.x branch. Right now I'm dealing as a I merge code from trunk to the branch, I'm dealing with merge conflicts in the attachment encoding code, which should have been in trunk all along.
>
> The only time when code shouldn't go into trunk is when it's doesn't at all apply to trunk, because the code in trunk has already diverged because of post-1.0 feature work.
>
> -Damien