Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Juanma Barranquero <address@hidden> writes:
>On Tue, Dec 29, 2009 at 05:46, Óscar Fuentes <address@hidden> wrote:
>> Personally, if I were a hacker doing quick contributions to emacs (the
>> sort of thing that ends on one single commit), I would use the
>> centralized workflow.
>
>And you would likely get some heat the nth time that you accidentally
>committed half-done changes, incomplete changelog entries, partial
>commits, etc. All the things that you can do in your local, non-bound
>branch and then fix at your own pace before sending it upstream. At
>least, I would (receive the heat, I mean, because I would likely do
>these mistakes).
>
>I know that I'm not saying anything that you don't know; also that
>you've insisted that we're developing Emacs, not creating the
>best-looking commit log ever. But it seems best to start recommending
>safer, cleaner practices. People who knows better, knows enough to
>bypass the recommendations.

Remember, during the transition, the point of
http://www.emacswiki.org/emacs-en/BzrForEmacsDevs was to offer a
reliable, safe, and simple method for continuing to work.  That way, no
one would shoot themselves (or the project) in the foot while learning
how to use Bazaar.  This naturally involved compromises.

Soon, though, developers (like Kenichi Handa) will be more familiar and
comfortable with Bazaar.  Once that happens, they *will* start looking
for ways to get around annoyances -- such as the need to do two commits
with two log messages (!) even for simple typo changes.

This is inevitable; if we deny this reality, we simply make the doc less
useful.  We always expected there would be adjustments to the doc once
we actually started using Bazaar; now we're hitting the first of those.

So at some point, I think it might be good to add Oscar's proposed
bound-branch-for-really-truly-one-commit-fixes method to the
documentation, as an option.  The recipe needed to be simple for the
transition, but it can get a *little* more complicated after that.  We
could recommend that the branch be called "oneoffs" or something.

Óscar, does your proposed workflow look like this?:

  ### Prepare the branch:
  $ cd $DEVHOME/emacs
  $ bzr branch trunk oneoffs
  $ cd oneoffs
  $ echo "public_branch = 
sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/trunk" >> 
.bzr/branch/branch.conf
  $ bzr bind sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/trunk

  ### To make a truly one-off typo fix, do this:
  $ cd $DEVHOME/emacs/oneoffs
  $ bzr update
  $ <<< edit to make the change, & edit the appropriate ChangeLog >>>
  $ bzr update
  $ <<< resolve any conflicts >>>
  $ bzr commit -m "* README: Fix typo."

(I want to be absolutely clear on what we're talking about, before we
figure out whether and how to document it.)

-Karl