You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2013/05/14 19:32:47 UTC
[REQUEST] Merge changes for CouchDB 1.3.1
Dear community,
We plan to release CouchDB 1.3.1 this month.
# Tidying up the release branch
To get a list of chnages on 1.3.x since we made the 1.3.0 release, run:
git log --abbrev-commit --pretty=oneline 1.3.0..1.3.x
Right now, this is showing:
869f42e COUCHDB-1788 - tolerate undefined source/target when reading
_replicator docs
9d41ea8 Make cardinality of result explicit, remove join hacks
bd0342d Add entries to NEWS and CHANGES for documentation
4d939c3 Add 1.3.1 section to NEWS and CHANGES
5e64395 Stop couchdb test server instance after javascript tests
complete.
37341af Add return value to waitForSuccess method.
9838eef Refactor javascript runner script to handle couchdb restarts.
Single interpreter per test.
0208778 PUT call to database that is not guaranted to exist.
6bbb1cc Remove setup functions from test runner, only allow a single
test to be run at a time.
e1bfac2 Added supplementary functions for running tests from command
line.
The CHANGES entry for 1.3.1 is showing:
*Nothing*
The NEWS entry for 1.3.1 is showing:
*Nothing*
Please take the time to edit these files so that they reflect the existing
changes on this branch.
# Merging fixes into master
This is also the time to consider whether you have any fixes that could
land in master, and by extension, the 1.3.x branch. If you've been working
on a branch, please review your changes, and merge in anything that seems
appropriate.
You can review your changes against master by running:
git log --abbrev-commit --pretty=oneline FROM..TO
If you can think of any other command that would help, or any tooling we
might want to make, please let me know. I'd like these emails to make
things as easy as possible for people to just run a few commands and get
the right stuff merged into the right places.
# Merging master into the release branch
Because the 1.3.x branch is the most release branch, all changes on master
should be merged into it before we do the release.
TODO: What Git command best shows this? "git log --pretty=oneline
1.3.x..master" produces lost of spurious results. Bob tells me this is
because we've been doing a lot of cherry-picking. I really want to figure
out how we can make this easier to do. Perhaps even something kludgy like a
script that runs this, but greps out known commits that don't count.
TODO: Can someone please figure out what the true diff is (by diff, I
really mean log) and share it with the list, or better yet, just merge it
in. Either way. I'd like to know how to run this off myself in future so I
can send it out with these emails.
Thanks for your help. This is going to be rough the first time we do it.
But these regular releases should be massively beneficial to the project,
and we will get better at them with practice (and automation).
For more information, see:
http://wiki.apache.org/couchdb/Release_Procedure#Timetable
For the release calendar, see:
http://wiki.apache.org/couchdb/Release_Calendar
Per the release procedure, I will start a DISCUSS thread in one week, so I
am hoping most of the changes have been made by then.
Thanks,
--
NS
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 14 May 2013 19:32, Noah Slater <ns...@apache.org> wrote:
> Dear community,
>
> We plan to release CouchDB 1.3.1 this month.
>
> # Tidying up the release branch
>
> To get a list of chnages on 1.3.x since we made the 1.3.0 release, run:
>
> git log --abbrev-commit --pretty=oneline 1.3.0..1.3.x
>
> Right now, this is showing:
>
> 869f42e COUCHDB-1788 - tolerate undefined source/target when reading
> _replicator docs
> 9d41ea8 Make cardinality of result explicit, remove join hacks
> bd0342d Add entries to NEWS and CHANGES for documentation
> 4d939c3 Add 1.3.1 section to NEWS and CHANGES
> 5e64395 Stop couchdb test server instance after javascript tests
> complete.
> 37341af Add return value to waitForSuccess method.
> 9838eef Refactor javascript runner script to handle couchdb restarts.
> Single interpreter per test.
> 0208778 PUT call to database that is not guaranted to exist.
> 6bbb1cc Remove setup functions from test runner, only allow a single
> test to be run at a time.
> e1bfac2 Added supplementary functions for running tests from command
> line.
>
> The CHANGES entry for 1.3.1 is showing:
>
> *Nothing*
>
> The NEWS entry for 1.3.1 is showing:
>
> *Nothing*
>
> Please take the time to edit these files so that they reflect the existing
> changes on this branch.
>
> # Merging fixes into master
>
> This is also the time to consider whether you have any fixes that could
> land in master, and by extension, the 1.3.x branch. If you've been working
> on a branch, please review your changes, and merge in anything that seems
> appropriate.
I'd add fixing zero-byte JSON issues as reported by Eli,
https://issues.apache.org/jira/browse/COUCHDB-1493
just needs some tests added.
A+
Dave
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Christopher Bonhage <qu...@me.com>.
Hi all,
I'd really like to see the fixes for COUCHDB-1368/COUCHDB-1639 merged into 1.3.x for 1.3.1 so that I can safely replicate attachments without denial-of-service attacking myself.
Thanks!
Christopher Bonhage
On May 14, 2013, at 10:32 AM, Noah Slater <ns...@apache.org> wrote:
> Dear community,
>
> We plan to release CouchDB 1.3.1 this month.
>
> # Tidying up the release branch
>
> To get a list of chnages on 1.3.x since we made the 1.3.0 release, run:
>
> git log --abbrev-commit --pretty=oneline 1.3.0..1.3.x
>
> Right now, this is showing:
>
> 869f42e COUCHDB-1788 - tolerate undefined source/target when reading
> _replicator docs
> 9d41ea8 Make cardinality of result explicit, remove join hacks
> bd0342d Add entries to NEWS and CHANGES for documentation
> 4d939c3 Add 1.3.1 section to NEWS and CHANGES
> 5e64395 Stop couchdb test server instance after javascript tests
> complete.
> 37341af Add return value to waitForSuccess method.
> 9838eef Refactor javascript runner script to handle couchdb restarts.
> Single interpreter per test.
> 0208778 PUT call to database that is not guaranted to exist.
> 6bbb1cc Remove setup functions from test runner, only allow a single
> test to be run at a time.
> e1bfac2 Added supplementary functions for running tests from command
> line.
>
> The CHANGES entry for 1.3.1 is showing:
>
> *Nothing*
>
> The NEWS entry for 1.3.1 is showing:
>
> *Nothing*
>
> Please take the time to edit these files so that they reflect the existing
> changes on this branch.
>
> # Merging fixes into master
>
> This is also the time to consider whether you have any fixes that could
> land in master, and by extension, the 1.3.x branch. If you've been working
> on a branch, please review your changes, and merge in anything that seems
> appropriate.
>
> You can review your changes against master by running:
>
> git log --abbrev-commit --pretty=oneline FROM..TO
>
> If you can think of any other command that would help, or any tooling we
> might want to make, please let me know. I'd like these emails to make
> things as easy as possible for people to just run a few commands and get
> the right stuff merged into the right places.
>
> # Merging master into the release branch
>
> Because the 1.3.x branch is the most release branch, all changes on master
> should be merged into it before we do the release.
>
> TODO: What Git command best shows this? "git log --pretty=oneline
> 1.3.x..master" produces lost of spurious results. Bob tells me this is
> because we've been doing a lot of cherry-picking. I really want to figure
> out how we can make this easier to do. Perhaps even something kludgy like a
> script that runs this, but greps out known commits that don't count.
>
> TODO: Can someone please figure out what the true diff is (by diff, I
> really mean log) and share it with the list, or better yet, just merge it
> in. Either way. I'd like to know how to run this off myself in future so I
> can send it out with these emails.
>
> Thanks for your help. This is going to be rough the first time we do it.
> But these regular releases should be massively beneficial to the project,
> and we will get better at them with practice (and automation).
>
> For more information, see:
>
> http://wiki.apache.org/couchdb/Release_Procedure#Timetable
>
> For the release calendar, see:
>
> http://wiki.apache.org/couchdb/Release_Calendar
>
> Per the release procedure, I will start a DISCUSS thread in one week, so I
> am hoping most of the changes have been made by then.
>
> Thanks,
>
>
> --
> NS
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Randall Leeds <ra...@gmail.com>.
On Fri, May 17, 2013 at 12:55 PM, Noah Slater <ns...@apache.org> wrote:
> Not sure, Randal. Dave was asking similar things on IRC today.
>
> We need to drive that to conclusion. (Unfortunately, I'm not your man for
> that. Git is not my wheelhouse.)
>
>
> On 17 May 2013 19:59, Randall Leeds <ra...@gmail.com> wrote:
>
>> Where are we with merge procedure? What's the workflow we want to see
>> for master -> 1.3.1?
I just asked this as a question to me G+ coder circles. If you're
among these people you should be able to see it. If not, I'm repasting
it below.
https://plus.google.com/111071362103966336217/posts/2kBcJP87TCh
tl;dr -- I think if all fixes land via a merge we can see which things
haven't been backported with one git command. In cases where a
backport is not straightforward enough to just merge to the release
branch then making a branch off the fix branch to massage the change
for backport should ensure that, as far as git can tell, the original
fix branch "made it" into the release branch and the master branch.
This requires enforcing that all bug fixes land as merge commits. I
don't see another, less onerous, way to preserve the history required
for at-a-glance checking of backport status.
---
What git workflow tips do people have for dealing with multiple
supported branches. When you have a bugfix that should land in
multiple places do you always do it as a merge or cherry-pick to
backport? When backporting requires changes vis-a-vis the original fix
that go beyond what autoresolves in a merge do you create a backport
branch?
I'm thinking something like:
- All fixes (as opposed to features, which are not candidates for
backporting) should go in branches.
- All such branches should land with --no-ff
- Backports should have branches named
<fix-branch-name>-backport(-<optional_backport_release_branch_version>).
For example, 1012-fix-some-bug and 1021-fix-some-bug-backport-1.3.x.
The thinking goes as follows. If every fix has a merge commit on
master and every backport merged to X.Y.Z release branch is either a
merge commit pointing at the same fix or a backport branch descending
therefrom then `git log --merges X.Y.Z..master` should show all the
fixes that haven't been backported.
Is that correct?
--
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Not sure, Randal. Dave was asking similar things on IRC today.
We need to drive that to conclusion. (Unfortunately, I'm not your man for
that. Git is not my wheelhouse.)
On 17 May 2013 19:59, Randall Leeds <ra...@gmail.com> wrote:
> Where are we with merge procedure? What's the workflow we want to see
> for master -> 1.3.1?
>
> 1.3.1 is cut from 1.3.x I assume. But you asked a lot of questions
> about how to make it easier to see the differences.
>
> The best I could come up with to satisfy your question would have been
> to insist that *every single commit* on master be a merge commit and
> that those same merged heads could be merged to 1.3.x. That would, I
> think, make a log like "--first-parent 1.3.x..master" show only the
> ones that haven't been backported (I think).
>
> I already applied at least one fix via cherry-picking. I'll put it in
> CHANGES.
>
> On Fri, May 17, 2013 at 4:51 AM, Noah Slater <ns...@apache.org> wrote:
> > Friendly bump.
> >
> > NEWS and CHANGES are still empty.
> >
> > I'll be calling the vote on 1.3.1 in 12 days, so y'all better get your
> > changes in pronto! ;)
> >
> >
> > On 15 May 2013 07:24, Dave Cottlehuber <dc...@jsonified.com> wrote:
> >
> >> On 15 May 2013 06:17, Benoit Chesneau <bc...@gmail.com> wrote:
> >> > On May 15, 2013 12:06 AM, "Dave Cottlehuber" <dc...@jsonified.com>
> wrote:
> >> >>
> >> >> On 14 May 2013 23:24, Robert Newson <rn...@apache.org> wrote:
> >> >> >
> >> >> > I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
> >> >> >
> >> >> > B.
> >> >>
> >> >
> >> > this can't happen since it removes the r13 compatibility. imo it has
> to
> >> > wait for 1.4.
> >> >
> >> > in the mean rime ws could port the patch from macport to give the
> >> > compatibility with r16... This parse_transform works well.
> >> >
> >> > - benoit
> >>
> >> Seems sensible.
> >>
> >
> >
> >
> > --
> > NS
>
--
NS
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Randall Leeds <ra...@gmail.com>.
Where are we with merge procedure? What's the workflow we want to see
for master -> 1.3.1?
1.3.1 is cut from 1.3.x I assume. But you asked a lot of questions
about how to make it easier to see the differences.
The best I could come up with to satisfy your question would have been
to insist that *every single commit* on master be a merge commit and
that those same merged heads could be merged to 1.3.x. That would, I
think, make a log like "--first-parent 1.3.x..master" show only the
ones that haven't been backported (I think).
I already applied at least one fix via cherry-picking. I'll put it in CHANGES.
On Fri, May 17, 2013 at 4:51 AM, Noah Slater <ns...@apache.org> wrote:
> Friendly bump.
>
> NEWS and CHANGES are still empty.
>
> I'll be calling the vote on 1.3.1 in 12 days, so y'all better get your
> changes in pronto! ;)
>
>
> On 15 May 2013 07:24, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
>> On 15 May 2013 06:17, Benoit Chesneau <bc...@gmail.com> wrote:
>> > On May 15, 2013 12:06 AM, "Dave Cottlehuber" <dc...@jsonified.com> wrote:
>> >>
>> >> On 14 May 2013 23:24, Robert Newson <rn...@apache.org> wrote:
>> >> >
>> >> > I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
>> >> >
>> >> > B.
>> >>
>> >
>> > this can't happen since it removes the r13 compatibility. imo it has to
>> > wait for 1.4.
>> >
>> > in the mean rime ws could port the patch from macport to give the
>> > compatibility with r16... This parse_transform works well.
>> >
>> > - benoit
>>
>> Seems sensible.
>>
>
>
>
> --
> NS
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Friendly bump.
NEWS and CHANGES are still empty.
I'll be calling the vote on 1.3.1 in 12 days, so y'all better get your
changes in pronto! ;)
On 15 May 2013 07:24, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 15 May 2013 06:17, Benoit Chesneau <bc...@gmail.com> wrote:
> > On May 15, 2013 12:06 AM, "Dave Cottlehuber" <dc...@jsonified.com> wrote:
> >>
> >> On 14 May 2013 23:24, Robert Newson <rn...@apache.org> wrote:
> >> >
> >> > I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
> >> >
> >> > B.
> >>
> >
> > this can't happen since it removes the r13 compatibility. imo it has to
> > wait for 1.4.
> >
> > in the mean rime ws could port the patch from macport to give the
> > compatibility with r16... This parse_transform works well.
> >
> > - benoit
>
> Seems sensible.
>
--
NS
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 15 May 2013 06:17, Benoit Chesneau <bc...@gmail.com> wrote:
> On May 15, 2013 12:06 AM, "Dave Cottlehuber" <dc...@jsonified.com> wrote:
>>
>> On 14 May 2013 23:24, Robert Newson <rn...@apache.org> wrote:
>> >
>> > I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
>> >
>> > B.
>>
>
> this can't happen since it removes the r13 compatibility. imo it has to
> wait for 1.4.
>
> in the mean rime ws could port the patch from macport to give the
> compatibility with r16... This parse_transform works well.
>
> - benoit
Seems sensible.
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Benoit Chesneau <bc...@gmail.com>.
On May 15, 2013 12:06 AM, "Dave Cottlehuber" <dc...@jsonified.com> wrote:
>
> On 14 May 2013 23:24, Robert Newson <rn...@apache.org> wrote:
> >
> > I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
> >
> > B.
>
this can't happen since it removes the r13 compatibility. imo it has to
wait for 1.4.
in the mean rime ws could port the patch from macport to give the
compatibility with r16... This parse_transform works well.
- benoit
>
> That's doable, I started on 1.3.x branch originally. I'll do an
> updated branch tomorrow.
>
> NB the reason this didn't go to 1.3.0 branch was that it also drops
> support for < R14B, viz sha#d751a3914.
>
> How does that sit with people & packagers?
>
> A+
> Dave
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 14 May 2013 23:24, Robert Newson <rn...@apache.org> wrote:
>
> I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
>
> B.
That's doable, I started on 1.3.x branch originally. I'll do an
updated branch tomorrow.
NB the reason this didn't go to 1.3.0 branch was that it also drops
support for < R14B, viz sha#d751a3914.
How does that sit with people & packagers?
A+
Dave
Re: [REQUEST] Merge changes for CouchDB 1.3.1
Posted by Robert Newson <rn...@apache.org>.
I'd like to see the mochiweb work for R16 compatibility in 1.3.1.
B.
On 14 May 2013 18:32, Noah Slater <ns...@apache.org> wrote:
> Dear community,
>
> We plan to release CouchDB 1.3.1 this month.
>
> # Tidying up the release branch
>
> To get a list of chnages on 1.3.x since we made the 1.3.0 release, run:
>
> git log --abbrev-commit --pretty=oneline 1.3.0..1.3.x
>
> Right now, this is showing:
>
> 869f42e COUCHDB-1788 - tolerate undefined source/target when reading
> _replicator docs
> 9d41ea8 Make cardinality of result explicit, remove join hacks
> bd0342d Add entries to NEWS and CHANGES for documentation
> 4d939c3 Add 1.3.1 section to NEWS and CHANGES
> 5e64395 Stop couchdb test server instance after javascript tests
> complete.
> 37341af Add return value to waitForSuccess method.
> 9838eef Refactor javascript runner script to handle couchdb restarts.
> Single interpreter per test.
> 0208778 PUT call to database that is not guaranted to exist.
> 6bbb1cc Remove setup functions from test runner, only allow a single
> test to be run at a time.
> e1bfac2 Added supplementary functions for running tests from command
> line.
>
> The CHANGES entry for 1.3.1 is showing:
>
> *Nothing*
>
> The NEWS entry for 1.3.1 is showing:
>
> *Nothing*
>
> Please take the time to edit these files so that they reflect the existing
> changes on this branch.
>
> # Merging fixes into master
>
> This is also the time to consider whether you have any fixes that could
> land in master, and by extension, the 1.3.x branch. If you've been working
> on a branch, please review your changes, and merge in anything that seems
> appropriate.
>
> You can review your changes against master by running:
>
> git log --abbrev-commit --pretty=oneline FROM..TO
>
> If you can think of any other command that would help, or any tooling we
> might want to make, please let me know. I'd like these emails to make
> things as easy as possible for people to just run a few commands and get
> the right stuff merged into the right places.
>
> # Merging master into the release branch
>
> Because the 1.3.x branch is the most release branch, all changes on master
> should be merged into it before we do the release.
>
> TODO: What Git command best shows this? "git log --pretty=oneline
> 1.3.x..master" produces lost of spurious results. Bob tells me this is
> because we've been doing a lot of cherry-picking. I really want to figure
> out how we can make this easier to do. Perhaps even something kludgy like a
> script that runs this, but greps out known commits that don't count.
>
> TODO: Can someone please figure out what the true diff is (by diff, I
> really mean log) and share it with the list, or better yet, just merge it
> in. Either way. I'd like to know how to run this off myself in future so I
> can send it out with these emails.
>
> Thanks for your help. This is going to be rough the first time we do it.
> But these regular releases should be massively beneficial to the project,
> and we will get better at them with practice (and automation).
>
> For more information, see:
>
> http://wiki.apache.org/couchdb/Release_Procedure#Timetable
>
> For the release calendar, see:
>
> http://wiki.apache.org/couchdb/Release_Calendar
>
> Per the release procedure, I will start a DISCUSS thread in one week, so I
> am hoping most of the changes have been made by then.
>
> Thanks,
>
>
> --
> NS