From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.bugs Subject: bug#7548: [FIXED] bookmark-default-handler wrong documentation Date: Sun, 12 Dec 2010 15:47:26 -0500 Message-ID: <87y67ubtwh.fsf@red-bean.com> References: <87r5dsd6nw.fsf@red-bean.com> <87hbejc4ir.fsf@red-bean.com> <83hbeiu49i.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1292187160 11423 80.91.229.12 (12 Dec 2010 20:52:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Dec 2010 20:52:40 +0000 (UTC) Cc: cyd@stupidchicken.com, 7548@debbugs.gnu.org, sdl.web@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 12 21:52:32 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsuG-00089g-FO for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 Dec 2010 21:52:32 +0100 Original-Received: from localhost ([127.0.0.1]:53978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRsuF-0007dE-MT for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 Dec 2010 15:52:31 -0500 Original-Received: from [140.186.70.92] (port=33281 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRsuA-0007aq-0V for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2010 15:52:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRsu9-0005ZL-26 for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2010 15:52:25 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRsu9-0005ZG-0i for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2010 15:52:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PRsk6-0002I8-8P; Sun, 12 Dec 2010 15:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Karl Fogel Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2010 20:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7548 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7548-submit@debbugs.gnu.org id=B7548.12921864818706 (code B ref 7548); Sun, 12 Dec 2010 20:42:02 +0000 Original-Received: (at 7548) by debbugs.gnu.org; 12 Dec 2010 20:41:21 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsjQ-0002GM-9q for submit@debbugs.gnu.org; Sun, 12 Dec 2010 15:41:20 -0500 Original-Received: from osh-net-219-98.onshore.net ([66.146.219.98] helo=sanpietro.red-bean.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRsjO-0002G9-Dd for 7548@debbugs.gnu.org; Sun, 12 Dec 2010 15:41:19 -0500 Original-Received: from localhost ([127.0.0.1]:39424 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.72) (envelope-from ) id 1PRspL-0000Dr-25; Sun, 12 Dec 2010 14:47:27 -0600 In-Reply-To: <83hbeiu49i.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Dec 2010 22:26:17 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 12 Dec 2010 15:42:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:42449 Archived-At: Eli Zaretskii writes: >> I generally just put things on trunk and trust they will make it into a >> release at some point. > >We generally do it the other way around: changes that are safe for the >release branch should be committed there, and they will then be merged >to the trunk (unless you instruct otherwise, see below). Is this documented somewhere? (I think I recall having this discussion on-list before.) If one just always commits to trunk, then one doesn't have to ponder whether one's changes are safe for the upcoming release or not -- one knows the changes will eventually make it into mainline releases. Since these changes were about the long-term health of bookmark.el, and were not bugfixes intended for this particular release, committing to trunk seems like the better route in this case anyway. >> However, if you can point me to some >> documentation about the proper way to put things on release branches > >It's very simple: > > . create a clone of the "emacs-23" branch ("bzr branch --bind") > . commit changes that are appropriate there instead of to the trunk > . if a change committed to the branch should not be merged to the > trunk, put some prominent verbiage into the log message > . commit to the trunk only changes that are inappropriate for the > release branch This gets us closer to documentation; once honed, I can put it in a file in the tree somewhere findable. But first: Where does a developer look in order to find out that we're currently in a "commit to branches not to trunk" state? In other words, how would I know that today I should branch from the 'emacs-23' branch instead of trunk, but that tomorrow (or whenever) trunk is the default again? One can watch the mailing list, but it's rather high traffic, and doing it that way makes us keep state in our heads -- error-prone -- that could instead be maintained by machines. For example: during this period, trunk could simply reject changes whose commit message doesn't contain a special string, and the rejection message would contain instructions explaining what branch to commit to instead, and what the special string to use is if one really needs to commit to trunk. (I don't know how to set that up in bzr, though.) -Karl