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/21 21:30:21 UTC
[REQUEST] [REMINDER] 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:
b03809c docs: improve language, structure in CORS section
3c0287c docs: fold section on CORS into configuration chapter
866c8eb docs: move sections on vhosts, URL rewriting into configuration
chapter
dc55fbb Skip R15B01, R15B, R14B03 for Travis tests.
ef552f5 docs: update Makefile.am for recent section folding
13ae34d docs: move section on HTTP proxying into configuration chapter
cacc3c2 docs: move section on SSL support into configuration chapter
150a32a docs: move section on OS daemons into configuration chapter
fe9d094 docs: merge API introduction and actual reference material
47fc332 docs: move section on HTTP range requests into API chapter
f31f608 docs: add error handling code to EventSource example
7acfc5b Fix errors in, improve style of EventSource example code.
fb6d995 Note the need for allowing CORS for EventSource feeds.
b6433c2 Fix grammar in EventSource feed type introduction.
a246d43 docs: fix Sphinx warning
fe56a84 docs: improve language, consistency in CommonJS section
c1476e9 docs: improve language, consistency in JS query server section
e4cfc40 docs: improve language in Erlang query server section.
24b1e8a Mention CORS support in 1.3.0 changelog.
06f1a8d Don't log missing '.compact' file when compacting
7308432 remove bogus NEWS entry
a1a98c0 Fix bad merge of WARN level logging
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 pull requests and patches
This is also a good time to review an JIRA tickets that have patches that
are just waiting for a committer to apply them. If you are a committer,
please apply the patches and close out the ticket. If you're not a
committer, please alert someone so they can do this for you.
TODO: What is a good URL for a search for tickets like this?
Please also review our pull requests on GitHub:
https://github.com/apache/couchdb/pulls
Specifically, these might be candidates for the release:
Service stop was not working as pid file was not cleared.
https://github.com/apache/couchdb/pull/59
Extend documentation on replication
https://github.com/apache/couchdb/pull/58
[couch_doc] revid_to_str: account for the case when the RevId is a list
of binaries
https://github.com/apache/couchdb/pull/57
Added RedHat based distribution installation information to docs.
https://github.com/apache/couchdb/pull/50
Not sure if these are features or bugfixes, but highlighting them anyway:
COUCHDB-259 allow arbitrary data to be stored along attachments
https://github.com/apache/couchdb/pull/54
COUCHDB-259 allow content_type of attachments to be changed via stub
https://github.com/apache/couchdb/pull/51
# 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 VOTE thread in one week, so I am
hoping all of the changes have been made by then.
Thanks,
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Wendall Cada <we...@apache.org>.
I have assumed responsibility for a few of these items and they are
assigned to me in Jira. I'll have time this weekend to process through
these and give response, push code, etc. Busy at work, so haven't had
much time, but will give this some love soon!
Wendall
On 05/21/2013 12:30 PM, Noah Slater 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:
>
> b03809c docs: improve language, structure in CORS section
> 3c0287c docs: fold section on CORS into configuration chapter
> 866c8eb docs: move sections on vhosts, URL rewriting into configuration
> chapter
> dc55fbb Skip R15B01, R15B, R14B03 for Travis tests.
> ef552f5 docs: update Makefile.am for recent section folding
> 13ae34d docs: move section on HTTP proxying into configuration chapter
> cacc3c2 docs: move section on SSL support into configuration chapter
> 150a32a docs: move section on OS daemons into configuration chapter
> fe9d094 docs: merge API introduction and actual reference material
> 47fc332 docs: move section on HTTP range requests into API chapter
> f31f608 docs: add error handling code to EventSource example
> 7acfc5b Fix errors in, improve style of EventSource example code.
> fb6d995 Note the need for allowing CORS for EventSource feeds.
> b6433c2 Fix grammar in EventSource feed type introduction.
> a246d43 docs: fix Sphinx warning
> fe56a84 docs: improve language, consistency in CommonJS section
> c1476e9 docs: improve language, consistency in JS query server section
> e4cfc40 docs: improve language in Erlang query server section.
> 24b1e8a Mention CORS support in 1.3.0 changelog.
> 06f1a8d Don't log missing '.compact' file when compacting
> 7308432 remove bogus NEWS entry
> a1a98c0 Fix bad merge of WARN level logging
> 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 pull requests and patches
>
> This is also a good time to review an JIRA tickets that have patches that
> are just waiting for a committer to apply them. If you are a committer,
> please apply the patches and close out the ticket. If you're not a
> committer, please alert someone so they can do this for you.
>
> TODO: What is a good URL for a search for tickets like this?
>
> Please also review our pull requests on GitHub:
>
> https://github.com/apache/couchdb/pulls
>
> Specifically, these might be candidates for the release:
>
> Service stop was not working as pid file was not cleared.
> https://github.com/apache/couchdb/pull/59
>
> Extend documentation on replication
> https://github.com/apache/couchdb/pull/58
>
> [couch_doc] revid_to_str: account for the case when the RevId is a list
> of binaries
> https://github.com/apache/couchdb/pull/57
>
> Added RedHat based distribution installation information to docs.
> https://github.com/apache/couchdb/pull/50
>
> Not sure if these are features or bugfixes, but highlighting them anyway:
>
> COUCHDB-259 allow arbitrary data to be stored along attachments
> https://github.com/apache/couchdb/pull/54
>
> COUCHDB-259 allow content_type of attachments to be changed via stub
> https://github.com/apache/couchdb/pull/51
>
> # 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 VOTE thread in one week, so I am
> hoping all of the changes have been made by then.
>
> Thanks,
>
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
It sounds like you have a very good idea of how to solve our problems! I
suggest you run with it! :D As you mention, probably best to spin this out
to another thread. (Or tac it on to the end of the existing "[DISCUSS] Git
workflow" thread. We really need to drive that to conclusion as soon as
possible.) Ideally, once we've agreed on what we want to do here, someone
moves it to the wiki, and we let it mature there for a while, before moving
to the docs.
Randall, can you also help me prepare the commands / instructions to send
out at the various points during the release cycle? I'd like to have
copy-and-paste-able things people can use to help them get things sorted.
On 22 May 2013 02:29, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <ra...@gmail.com>
> wrote:
> > Here's a diagram. In this I show a feature branch landing on master
> > and a backport of it landing on 1.3.x, but if we follow the procedure
> > I'm suggesting I think it can even be easy to keep track of
> > cherry-picked backports.
> >
> > https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
> >
> > The fancy things here are
> > * merge-base: to find the common ancestor
> > * --no-commit: so NEWS and CHANGES can be reconciled atomically with
> > respect to what the git logs will say is unmerged
> > * -Xours: so that we can merge release branches to master *without*
> > code changes, just to mark a point in history so that a future
> > merge-base will only show us what hasn't made it into NEWS and CHANGES
> > since we last did this.
>
> This last one is the key piece. By using the "ours" merge strategy we
> can mark at point in history where the *history* is said to be
> reconciled (we've updated NEWS and CHANGES in both merge parents)
> without accidentally forward-porting code changes. We can record new
> merge bases for the release branches vis-a-vis master, which makes
> reading the logs for NEWS and CHANGES maintenance easier, and at the
> same time we record the current state of NEWS and CHANGES.
>
> But maybe I'm overthinking it since one alternative is to just update
> NEWS and CHANGES whenever we make commits. However, I think if we just
> merge releases to master whenever we make a backport or a release then
> it will be a very quick and painless process to update NEWS and
> CHANGES when it comes time for 1.4.x.
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Ooh, good stuff Dirkjan.
If everything looks good, I'll be looking to prepare the candidate around
17:00 UTC.
On 27 May 2013 17:18, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Mon, May 27, 2013 at 3:53 PM, Noah Slater <ns...@apache.org> wrote:
> > Last day to get in changes and update these files. Release day is
> tomorrow.
>
> I've reviewed changes that are on master that seem like they are
> low-risk bug fixes (and as such, should also be shipped on 1.3.x).
>
> I found these:
>
> 4abe8cd9 - Merge remote-tracking branch
> 'ocasta/1799-rewrite-session-cookie-fix'
> Adam, does it make sense to merge it? Can you?
>
> 501459c8 - [couchjs] make stack size option effective (COUCHDB-1792)
> Randall, does it make sense to merge this? Can you?
>
> 73db8179 - COUCHDB-1696 really fix R14B04 support
> Dave, does it make sense to merge this? Can you?
>
> Also, Dave, does it make sense to try and enable R16B support for 1.3.x?
>
> If you are not able to merge your change, I'll try merging them
> tomorrow in the UTC morning (if others think it makes sense).
>
> Cheers,
>
> Dirkjan
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Randall Leeds <ra...@gmail.com>.
On Mon, May 27, 2013 at 9:18 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> 501459c8 - [couchjs] make stack size option effective (COUCHDB-1792)
> Randall, does it make sense to merge this? Can you?
Yes. Done. Updated NEWS and CHANGES.
I also copied the 1.3.1 entries for NEWS and CHANGES to master.
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Just wanted to bump this old thread to namecheck Randal, Dirkjan, and Dave
who did great work getting 1.3.x into shape for the arbitrary deadline I
picked for the vote. Thanks guys! Appreciated!
On 28 May 2013 15:40, Adam Kocoloski <ko...@apache.org> wrote:
> On May 27, 2013, at 12:18 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
> > 4abe8cd9 - Merge remote-tracking branch
> 'ocasta/1799-rewrite-session-cookie-fix'
> > Adam, does it make sense to merge it? Can you?
>
> Done (well, I cherry-picked ocasta's commit onto 1.3.x).
>
> Adam
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Adam Kocoloski <ko...@apache.org>.
On May 27, 2013, at 12:18 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> 4abe8cd9 - Merge remote-tracking branch 'ocasta/1799-rewrite-session-cookie-fix'
> Adam, does it make sense to merge it? Can you?
Done (well, I cherry-picked ocasta's commit onto 1.3.x).
Adam
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Mon, May 27, 2013 at 3:53 PM, Noah Slater <ns...@apache.org> wrote:
> Last day to get in changes and update these files. Release day is tomorrow.
I've reviewed changes that are on master that seem like they are
low-risk bug fixes (and as such, should also be shipped on 1.3.x).
I found these:
4abe8cd9 - Merge remote-tracking branch 'ocasta/1799-rewrite-session-cookie-fix'
Adam, does it make sense to merge it? Can you?
501459c8 - [couchjs] make stack size option effective (COUCHDB-1792)
Randall, does it make sense to merge this? Can you?
73db8179 - COUCHDB-1696 really fix R14B04 support
Dave, does it make sense to merge this? Can you?
Also, Dave, does it make sense to try and enable R16B support for 1.3.x?
If you are not able to merge your change, I'll try merging them
tomorrow in the UTC morning (if others think it makes sense).
Cheers,
Dirkjan
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Last day to get in changes and update these files. Release day is tomorrow.
If we're not ready for it, we miss the release. The next release window is
Tuesday 18th Jun.
If I can be of assistance, ping me and I'll do what I can to help out.
On 26 May 2013 14:44, Noah Slater <ns...@apache.org> wrote:
> Hey folks,
>
> NEWS and CHANGES are still empty for 1.3.1. Can we get these updated
> please? I'd like to cut the release on Tuesday.
>
> Thanks,
>
>
> On 24 May 2013 13:33, Noah Slater <ns...@apache.org> wrote:
>
>> What dave said! We can finalise our Git workflow later - for now, we have
>> 4 more days to muddle through this. (We'll get better over time. Not need
>> to be perfect right away.) So if you're feeling blocked (on process,
>> discussion, whatever) don't be! :)
>>
>>
>> On 24 May 2013 13:21, Dave Cottlehuber <dc...@jsonified.com> wrote:
>>
>>> Hi folks,
>>>
>>> Is anybody waiting on anything, or needing help with anything, for the
>>> road to 1.3.1 ? Or are you able to help with anything but not sure
>>> where?
>>>
>>> For example, I've got a couple things sitting in jira[1][2] that could
>>> do with a look, others are not sure whether the new git workflow
>>> should be applied.
>>>
>>> NB specifically re git, for the moment, continue as usual, feel free
>>> to merge[3] if you have the courage (you can always test your merge on
>>> a local branch anyway), the workflow is not finalised yet.
>>>
>>> A+
>>> Dave
>>>
>>> [1]: https://issues.apache.org/jira/browse/COUCHDB-1784
>>> [2]: https://issues.apache.org/jira/browse/COUCHDB-1783
>>> [3]: http://wiki.apache.org/couchdb/Merge_Procedure
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Hey folks,
NEWS and CHANGES are still empty for 1.3.1. Can we get these updated
please? I'd like to cut the release on Tuesday.
Thanks,
On 24 May 2013 13:33, Noah Slater <ns...@apache.org> wrote:
> What dave said! We can finalise our Git workflow later - for now, we have
> 4 more days to muddle through this. (We'll get better over time. Not need
> to be perfect right away.) So if you're feeling blocked (on process,
> discussion, whatever) don't be! :)
>
>
> On 24 May 2013 13:21, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
>> Hi folks,
>>
>> Is anybody waiting on anything, or needing help with anything, for the
>> road to 1.3.1 ? Or are you able to help with anything but not sure
>> where?
>>
>> For example, I've got a couple things sitting in jira[1][2] that could
>> do with a look, others are not sure whether the new git workflow
>> should be applied.
>>
>> NB specifically re git, for the moment, continue as usual, feel free
>> to merge[3] if you have the courage (you can always test your merge on
>> a local branch anyway), the workflow is not finalised yet.
>>
>> A+
>> Dave
>>
>> [1]: https://issues.apache.org/jira/browse/COUCHDB-1784
>> [2]: https://issues.apache.org/jira/browse/COUCHDB-1783
>> [3]: http://wiki.apache.org/couchdb/Merge_Procedure
>>
>
>
>
> --
> NS
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
What dave said! We can finalise our Git workflow later - for now, we have 4
more days to muddle through this. (We'll get better over time. Not need to
be perfect right away.) So if you're feeling blocked (on process,
discussion, whatever) don't be! :)
On 24 May 2013 13:21, Dave Cottlehuber <dc...@jsonified.com> wrote:
> Hi folks,
>
> Is anybody waiting on anything, or needing help with anything, for the
> road to 1.3.1 ? Or are you able to help with anything but not sure
> where?
>
> For example, I've got a couple things sitting in jira[1][2] that could
> do with a look, others are not sure whether the new git workflow
> should be applied.
>
> NB specifically re git, for the moment, continue as usual, feel free
> to merge[3] if you have the courage (you can always test your merge on
> a local branch anyway), the workflow is not finalised yet.
>
> A+
> Dave
>
> [1]: https://issues.apache.org/jira/browse/COUCHDB-1784
> [2]: https://issues.apache.org/jira/browse/COUCHDB-1783
> [3]: http://wiki.apache.org/couchdb/Merge_Procedure
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Dave Cottlehuber <dc...@jsonified.com>.
Hi folks,
Is anybody waiting on anything, or needing help with anything, for the
road to 1.3.1 ? Or are you able to help with anything but not sure
where?
For example, I've got a couple things sitting in jira[1][2] that could
do with a look, others are not sure whether the new git workflow
should be applied.
NB specifically re git, for the moment, continue as usual, feel free
to merge[3] if you have the courage (you can always test your merge on
a local branch anyway), the workflow is not finalised yet.
A+
Dave
[1]: https://issues.apache.org/jira/browse/COUCHDB-1784
[2]: https://issues.apache.org/jira/browse/COUCHDB-1783
[3]: http://wiki.apache.org/couchdb/Merge_Procedure
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Erm, sorry, Tuesday. :)
(And to clarify, I'm pumped we're having this conversation, I just
wanna separate the threads!)
On 22 May 2013 17:55, Noah Slater <ns...@apache.org> wrote:
> Can we move the rest of this discussion over to the "[DISCUSS] Git
> workflow" please. :)
>
> The focus of this thread is: what do we need to do to make sure we can
> call a successful vote on Thursday?
>
>
> On 22 May 2013 17:38, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
>> On Wed, May 22, 2013 at 3:29 AM, Randall Leeds <ra...@gmail.com>
>> wrote:
>> > On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <ra...@gmail.com>
>> wrote:
>> >> Here's a diagram. In this I show a feature branch landing on master
>> >> and a backport of it landing on 1.3.x, but if we follow the procedure
>> >> I'm suggesting I think it can even be easy to keep track of
>> >> cherry-picked backports.
>> >>
>> >> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
>> >>
>> >> The fancy things here are
>> >> * merge-base: to find the common ancestor
>>
>> As in, the common ancestor on a release branch? Because you don't want
>> to use the old feature branch head as ancestor, but rather the branch
>> point where the release branch deviated from master?
>>
>> >> * --no-commit: so NEWS and CHANGES can be reconciled atomically with
>> >> respect to what the git logs will say is unmerged
>>
>> Not sure why you'd need that here.
>>
>> >> * -Xours: so that we can merge release branches to master *without*
>> >> code changes, just to mark a point in history so that a future
>> >> merge-base will only show us what hasn't made it into NEWS and CHANGES
>> >> since we last did this.
>> >
>> > (snip)
>> >
>> > But maybe I'm overthinking it since one alternative is to just update
>> > NEWS and CHANGES whenever we make commits. However, I think if we just
>> > merge releases to master whenever we make a backport or a release then
>> > it will be a very quick and painless process to update NEWS and
>> > CHANGES when it comes time for 1.4.x.
>>
>> Yeah, I don't think we actually need the "ours" merge strategy here.
>>
>> I do think we should try merging from release branch to master some
>> time soon (e.g. after the next feature release).
>>
>> Cheers,
>>
>> Dirkjan
>>
>
>
>
> --
> NS
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Can we move the rest of this discussion over to the "[DISCUSS] Git
workflow" please. :)
The focus of this thread is: what do we need to do to make sure we can call
a successful vote on Thursday?
On 22 May 2013 17:38, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Wed, May 22, 2013 at 3:29 AM, Randall Leeds <ra...@gmail.com>
> wrote:
> > On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <ra...@gmail.com>
> wrote:
> >> Here's a diagram. In this I show a feature branch landing on master
> >> and a backport of it landing on 1.3.x, but if we follow the procedure
> >> I'm suggesting I think it can even be easy to keep track of
> >> cherry-picked backports.
> >>
> >> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
> >>
> >> The fancy things here are
> >> * merge-base: to find the common ancestor
>
> As in, the common ancestor on a release branch? Because you don't want
> to use the old feature branch head as ancestor, but rather the branch
> point where the release branch deviated from master?
>
> >> * --no-commit: so NEWS and CHANGES can be reconciled atomically with
> >> respect to what the git logs will say is unmerged
>
> Not sure why you'd need that here.
>
> >> * -Xours: so that we can merge release branches to master *without*
> >> code changes, just to mark a point in history so that a future
> >> merge-base will only show us what hasn't made it into NEWS and CHANGES
> >> since we last did this.
> >
> > (snip)
> >
> > But maybe I'm overthinking it since one alternative is to just update
> > NEWS and CHANGES whenever we make commits. However, I think if we just
> > merge releases to master whenever we make a backport or a release then
> > it will be a very quick and painless process to update NEWS and
> > CHANGES when it comes time for 1.4.x.
>
> Yeah, I don't think we actually need the "ours" merge strategy here.
>
> I do think we should try merging from release branch to master some
> time soon (e.g. after the next feature release).
>
> Cheers,
>
> Dirkjan
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, May 22, 2013 at 3:29 AM, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <ra...@gmail.com> wrote:
>> Here's a diagram. In this I show a feature branch landing on master
>> and a backport of it landing on 1.3.x, but if we follow the procedure
>> I'm suggesting I think it can even be easy to keep track of
>> cherry-picked backports.
>>
>> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
>>
>> The fancy things here are
>> * merge-base: to find the common ancestor
As in, the common ancestor on a release branch? Because you don't want
to use the old feature branch head as ancestor, but rather the branch
point where the release branch deviated from master?
>> * --no-commit: so NEWS and CHANGES can be reconciled atomically with
>> respect to what the git logs will say is unmerged
Not sure why you'd need that here.
>> * -Xours: so that we can merge release branches to master *without*
>> code changes, just to mark a point in history so that a future
>> merge-base will only show us what hasn't made it into NEWS and CHANGES
>> since we last did this.
>
> (snip)
>
> But maybe I'm overthinking it since one alternative is to just update
> NEWS and CHANGES whenever we make commits. However, I think if we just
> merge releases to master whenever we make a backport or a release then
> it will be a very quick and painless process to update NEWS and
> CHANGES when it comes time for 1.4.x.
Yeah, I don't think we actually need the "ours" merge strategy here.
I do think we should try merging from release branch to master some
time soon (e.g. after the next feature release).
Cheers,
Dirkjan
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <ra...@gmail.com> wrote:
> Here's a diagram. In this I show a feature branch landing on master
> and a backport of it landing on 1.3.x, but if we follow the procedure
> I'm suggesting I think it can even be easy to keep track of
> cherry-picked backports.
>
> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
>
> The fancy things here are
> * merge-base: to find the common ancestor
> * --no-commit: so NEWS and CHANGES can be reconciled atomically with
> respect to what the git logs will say is unmerged
> * -Xours: so that we can merge release branches to master *without*
> code changes, just to mark a point in history so that a future
> merge-base will only show us what hasn't made it into NEWS and CHANGES
> since we last did this.
This last one is the key piece. By using the "ours" merge strategy we
can mark at point in history where the *history* is said to be
reconciled (we've updated NEWS and CHANGES in both merge parents)
without accidentally forward-porting code changes. We can record new
merge bases for the release branches vis-a-vis master, which makes
reading the logs for NEWS and CHANGES maintenance easier, and at the
same time we record the current state of NEWS and CHANGES.
But maybe I'm overthinking it since one alternative is to just update
NEWS and CHANGES whenever we make commits. However, I think if we just
merge releases to master whenever we make a backport or a release then
it will be a very quick and painless process to update NEWS and
CHANGES when it comes time for 1.4.x.
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, May 21, 2013 at 5:55 PM, Noah Slater <ns...@apache.org> wrote:
> This is a little over my head. I'll wait to see what Bob things. (As he's
> my Git helper. Hehe.)
>
> Why would we ever commit a fix to 1.3.x and not to master? (Assuming 1.3.x
> is the most recent release branch.) My understanding of release branches is
> that we move things *to* them from other places, usually master.
>
> I think my main point is that at the point I cut the release, the code at
> the tip of 1.3.x and master should be identical. Are you thinking this too?
No. Master will eventually become 1.4.0 and may introduce new
features. Following semver dictates that these new features not land
in 1.3.1. Therefore, there will be commits on master which are not on
1.3.x.
>
> I'm not sure if our understanding differs in results, or differs in process.
Process. I'm just trying to improve the process.
Fixes could still originate on master.
Here's a diagram. In this I show a feature branch landing on master
and a backport of it landing on 1.3.x, but if we follow the procedure
I'm suggesting I think it can even be easy to keep track of
cherry-picked backports.
https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
The fancy things here are
* merge-base: to find the common ancestor
* --no-commit: so NEWS and CHANGES can be reconciled atomically with
respect to what the git logs will say is unmerged
* -Xours: so that we can merge release branches to master *without*
code changes, just to mark a point in history so that a future
merge-base will only show us what hasn't made it into NEWS and CHANGES
since we last did this.
I'm happy to explain further if it is not clear, but we should start a
separate thread if we go much further in this discussion.
For the present moment we should ensure that NEWS and CHANGES are
up-to-date on both 1.3.x and master in preparation for the 1.3.1
release and that any backports are done promptly.
I do think that this process will be easier in the future if we then
merge 1.3.x into to master. Doing this regularly reduces or eliminates
the need for anyone to sit and compare the release branch history and
the master history looking for what was backported and what wasn't. If
we merge the release branches to master any time we backport them and
record the NEWS and CHANGES since the last we did so there should
never be such duplicates when it comes time to release.
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
This is a little over my head. I'll wait to see what Bob things. (As he's
my Git helper. Hehe.)
Why would we ever commit a fix to 1.3.x and not to master? (Assuming 1.3.x
is the most recent release branch.) My understanding of release branches is
that we move things *to* them from other places, usually master.
I think my main point is that at the point I cut the release, the code at
the tip of 1.3.x and master should be identical. Are you thinking this too?
I'm not sure if our understanding differs in results, or differs in process.
On 22 May 2013 01:06, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, May 21, 2013 at 1:49 PM, Noah Slater <ns...@apache.org> wrote:
> > Docs changes are fine left out.
> >
> > Merges happen from master to the branch, not the other way around. I cut
> > the release from the branch, and tag from the branch.
> >
> > Because this is patch version of our latest release line, 1.3.x should
> have
> > all changes on master merged in before we release.
>
> I think Dirkjan may be right here. It may answer my question the other
> day about this.
>
> If we periodically merged release branches into master it would make
> maintaining NEWS and CHANGES easier.
>
> If we assume, for a moment, that master has its NEWS and CHANGES up to
> date at this point in time and then fixes have landed on 1.3.x, we can
> keep NEWS and CHANGES maintenance easy by merging 1.3.x to master
> periodically.
>
> First, we update the NEWS and CHANGES on 1.3.x.
>
> > git log 1.3.0..1.3.x
>
> This is what you showed earlier in this conversation. At this point
> we'd want to switch to 1.3.x and update NEWS and CHANGES.
>
> But we want to ensure that these NEWS and CHANGES items also make it
> into master so that these files don't get out of sync.
>
> Let's start the merge.
>
> > git merge --no-commit -Xours 1.3.x
>
> Now we have staged a merge of 1.3.x to master that makes no changes
> ("ours" strategy), but have not committed it.
>
> > git show 1.3.x:NEWS
>
> Copy the 1.3.x NEWS and CHANGES into the 1.3.1 (unreleased) section of
> the files.
>
>
> Next, we look to see the new features that have landed on master since
> we last did this.
>
> > git log --first-parent `git merge-base 1.3.x master`..master
>
> This gives us all the commits on master since 1.3.x and master
> diverged. Using --first-parent means we'll see the only the merge
> commits from feature branches. We'll also see any merges (of the kind
> I'm suggesting we create here) of other actively maintained branches,
> but it's still low noise, high signal command for listing new features
> introduced on master.
>
> Update the 1.4.0 sections in NEWS and CHANGES. Stage these files for
> commit.
>
> > git add NEWS CHANGES
>
> Now we can commit our merge. The contents of master won't change at
> all except that the unreleased sections of NEWS and CHANGES will be
> up-to-date. Once the merge is complete, we'll be able to follow this
> procedure again in the future to update these files incrementally.
>
> Another nice thing is that if people follow this procedure after doing
> any backporting work no one has to de-duplicate the logs later.
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, May 21, 2013 at 1:49 PM, Noah Slater <ns...@apache.org> wrote:
> Docs changes are fine left out.
>
> Merges happen from master to the branch, not the other way around. I cut
> the release from the branch, and tag from the branch.
>
> Because this is patch version of our latest release line, 1.3.x should have
> all changes on master merged in before we release.
I think Dirkjan may be right here. It may answer my question the other
day about this.
If we periodically merged release branches into master it would make
maintaining NEWS and CHANGES easier.
If we assume, for a moment, that master has its NEWS and CHANGES up to
date at this point in time and then fixes have landed on 1.3.x, we can
keep NEWS and CHANGES maintenance easy by merging 1.3.x to master
periodically.
First, we update the NEWS and CHANGES on 1.3.x.
> git log 1.3.0..1.3.x
This is what you showed earlier in this conversation. At this point
we'd want to switch to 1.3.x and update NEWS and CHANGES.
But we want to ensure that these NEWS and CHANGES items also make it
into master so that these files don't get out of sync.
Let's start the merge.
> git merge --no-commit -Xours 1.3.x
Now we have staged a merge of 1.3.x to master that makes no changes
("ours" strategy), but have not committed it.
> git show 1.3.x:NEWS
Copy the 1.3.x NEWS and CHANGES into the 1.3.1 (unreleased) section of
the files.
Next, we look to see the new features that have landed on master since
we last did this.
> git log --first-parent `git merge-base 1.3.x master`..master
This gives us all the commits on master since 1.3.x and master
diverged. Using --first-parent means we'll see the only the merge
commits from feature branches. We'll also see any merges (of the kind
I'm suggesting we create here) of other actively maintained branches,
but it's still low noise, high signal command for listing new features
introduced on master.
Update the 1.4.0 sections in NEWS and CHANGES. Stage these files for commit.
> git add NEWS CHANGES
Now we can commit our merge. The contents of master won't change at
all except that the unreleased sections of NEWS and CHANGES will be
up-to-date. Once the merge is complete, we'll be able to follow this
procedure again in the future to update these files incrementally.
Another nice thing is that if people follow this procedure after doing
any backporting work no one has to de-duplicate the logs later.
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Noah Slater <ns...@apache.org>.
Docs changes are fine left out.
Merges happen from master to the branch, not the other way around. I cut
the release from the branch, and tag from the branch.
Because this is patch version of our latest release line, 1.3.x should have
all changes on master merged in before we release.
On Tuesday, 21 May 2013, Dirkjan Ochtman wrote:
> On Tue, May 21, 2013 at 9:30 PM, Noah Slater <nslater@apache.org<javascript:;>>
> wrote:
> > 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.
>
> Personally, I don't think that docs refactoring needs to be mentioned
> in NEWS/CHANGES/changelog. Does anyone disagree?
>
> > # 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.
>
> Huh? Don't you mean that the other way around?
>
> > 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.
>
> In other projects, we used to keep release branches as a true subset
> of the master branch. That way, you can just keep merging the release
> branch into master branch periodically (for every batch of fixes you
> push). Would that work for this?
>
> > 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).
>
> Yay, thanks for the hard work!
>
> Cheers,
>
> Dirkjan
>
--
NS
Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Tue, May 21, 2013 at 9:30 PM, Noah Slater <ns...@apache.org> wrote:
> 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.
Personally, I don't think that docs refactoring needs to be mentioned
in NEWS/CHANGES/changelog. Does anyone disagree?
> # 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.
Huh? Don't you mean that the other way around?
> 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.
In other projects, we used to keep release branches as a true subset
of the master branch. That way, you can just keep merging the release
branch into master branch periodically (for every batch of fixes you
push). Would that work for this?
> 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).
Yay, thanks for the hard work!
Cheers,
Dirkjan