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

[Karl Fogel]

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