bug#7548: [FIXED] bookmark-default-handler wrong documentation

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: sdl.web@gmail.com,  7548@debbugs.gnu.org,  cyd@stupidchicken.com
> Date: Sun, 12 Dec 2010 15:47:26 -0500
> 
> Eli Zaretskii <eliz@gnu.org> 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 Stefan posted something like that here, but I cannot find it
now.

> (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.

The decision whether a particular change is important enough to have
in the next bugfix release is up to you; I just answered your
question.

> Where does a developer look in order to find out that we're currently in
> a "commit to branches not to trunk" state?

We are always in that state.  Changes that are safe for the branch
should be committed there at all times.  The branch is merged to the
trunk periodically.