Re: Emacs Bazaar repository

[Bastien <bzg@altern.org>]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>>  The assumption in the discussion so far has been namely this one: it is
>>  possible to use a dVCS instead of the current CVS without switching to a
>>  new project workflow.  Even better: most dVCS are so flexible that you
>>  can adapt your project workflow _after_ you start using one of them.
>
> This is one assumption. The other one is that all dVCS (or at least,
> the three or four "major" ones) are largely equivalent. Both seem to
> be false at this moment.

They are not equivalent in terms of performance, but I think the
assumption was more precisely that all dVCS are equivalent in terms of
their ability to adapt to any workflow.  This assumption is true IMO.

> Until now the Emacs model has been that everyone with write access is
> trusted to display some common sense, and it has worked quite well.

Sure, thanks to people on this mailing list!

> Limiting who can write to the canonical repository and establishing
> that kind of hierarchy seems like fixing a non-existent problem.

I didn't want to fix problems in the current workflow.

One of the benefits of using a dVCS is that you can envision different
workflows.  If everybody were okay with bzr then there would be no point
in trying to imagine other workflows before using the new dVCS.  But
since bzr has some annoying shortcomings, maybe it is useful to be sure
that everyone wants to stick to the current workflow before avoiding bzr
because of its inability to preserve this workflow...  

One of the shortcomings of the current workflow is this one: some piece
of code in Emacs is actively developped outside of the Emacs CVS (Gnus,
ERC, Org, etc.)  Since these pieces are also part of Emacs, any change
on them in the Emacs CVS requires someone to report the changes in the
local, independant repository of the module.  This is double work, and
such energy could be spared with the "Lieutenant" topology previously
described.

> As you say, it is a social issue. If I do a pervasive change in ido or
> cua, I *will* send it to Kim, for example; but I don't want to have to
> pass through someone to fix a typo or correct a silly oversight. 

I don't propose to sparse the code into areas where only one developer
can make changes.  I propose to think about what a _distributed_ VCS
would be really useful for as a collective tool, in hope that such a
discussion might give directions in the evaluation of bzr.

(Of course, a dVCS is already useful from an individual point of view:
being able to commit locally, to work on several local branches, all
this means it's already worth using a dVCS.  But bzr might also be
useful as a collective tool.)

> Let's not create bureaucracy until we know we need it.

Well, I believe the real benefit of a dVCS is precisely to avoid
bureaucracy -- provided that you can adapt the tool to the way people
want to work together with it, and this requires some discussion.

-- 
Bastien