Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <address@hidden> writes:

> Óscar Fuentes writes:
>
>  > Given the slow commit rate on the Emacs project, I see no problem using
>  > the quickfixes branch on a CVS-like way: bind it to upstream
>
> This encourages antisocial practices like per-file commits, and
> committing ChangeLog separate from the changes.

It doesn't encourage certain antisocial practices, just makes them
possible. This is easily solvable by monitoring the commits ml and
sending polite mails to those committers that do not follow good
practices, listing them. I volunteer to do that. The Emacs VC history
already contains thousands of revisions consisting on separate commits
for the same change. A few more is no problem.

>  Cf. the OP's
> description of his workflow.  It gets in the way of use of Bazaar
> features like "bzr log -n#" for other developers.

Uh? What's the benefit of log -n# for one-revision merges?

> That is a problem, if Emacs chooses to see it that way.
>
> If Emacs has no intention of improving its common workflow, then it's
> not a problem.  But if that's going to happen, there should be
> discussion of whether folks like the OP (who is in good company with
> the likes of rms and eliz) should be asked to invest the effort in a
> forward-compatible workflow now, or if Emacs should wait to make such
> improvements until the old-style workers are good and ready to accept
> such changes (presumably due to retirement<wink>, since it will be
> just as hard later as it is now, so they'll resist it then, too).

Well, there is no reason to settle on one Golden Workflow. It is clear
that we want to introduce new good practices on how the VC history is
developed (one changeset per purpose, etc) but that practices are not
incompatible with multiple workflows. The feature branches workflow is
great for substantial changes, but a PITA for one-liners. The
centralized workflow is perfectly okay (unless you abuse it, or course,
but you can abuse the distributed one: what stops you from mixing
unrelated changes on the same merge?)

Since long time ago I think that the main problem most people here have
with the transition to bazaar is that they lack an insight on what a
DVCS is (and some even have no previous experience with changeset-based
VCSs!) People can understand the centralized usage of bzr without too
much effort, but pushing some hackers here to blindly use the
distributed workflow is asking for problems. A gradual introduction with
a simpler workflow helps in several ways. That's a personal decission,
no other is affected by it.

Please lets not forget that this is not about making Emacs a model of
orthodoxy in DVCS usage. It's about giving hackers a tool that helps
them to contribute to Emacs.

-- 
Óscar