Re: Emacs Bazaar repository

[Bastien]

dhruva <address@hidden> writes:

> I just hope it the decision is based on technical facts rather than
> affiliations and emotions...

I think the right dimension to consider is the social one.

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 has been specifically stated in Stephen J. Turnbull's post (from
January 08):

  http://article.gmane.org/gmane.emacs.devel/86530

> Thus I suggest that the project workflow discussion be postponed until
> the core stakeholders are satisfied that the new tools are functioning
> stably in the current workflow.  This will take only a month, at most
> two, once the tools are chosen.  As you point out, a big advantage of
> a dVCS is the flexibility of the workflow even after it is installed.
> There is no big loss to waiting a bit, and a potential large gain: the
> improved understanding of the tools that the core stakeholders will
> have.

... and this is clearly *true* when the use of the dVCS system is not
problematic /per se/.

Now we are in a situation where the decision for the dVCS has been made
(bzr) and yet this decision is not satisfactory for many of us. 

So instead of trying to convince 120 developpers to use bzr in its
current unsatisfactory state, maybe it's time to open the discussion
about the project workflow, and see if the number of people to convince
cannot be reduced by such a discussion.

Now referring to Gregory Collins' post[1] about the different workflows,
I think the current workflow for Emacs would be translated into a mix of
the "star" topology (where many developers are entitled to write in any
part of the codebase) and the "Lieutenant" topology (where the majority
of developers are responsible for subsystems.)

This would mean that some core developers have access to all the code,
and need to agree about when bzr is good enough, and other developers
are free to use whatever they want, provided that they send patches in
the form that the core developers prefer.

I guess at most 25% of the current 120 developers would need to have
access to all the code.  The rest would be responsible for a limited
part -- either a large directory like Gnus or a single Elisp file.

Of course, it would be easier if all the Lieutenants were using bzr,
because the core team would just need to pull from the lieutenants
repositories.  But the only true requisit is that lieutenants keep
pulling from the Emacs codebase and make sure the code they are
responsible for works correctly with the latest Emacs code.

We spent time learning that the radical change with dVCS is that 
they move the constraints for the workflow from the technical to 
the social dimension.  It's strange that the discussion about bzr 
is just a technical one, without consideration about the social 
change this already calls for.

Notes: 
[1]  http://article.gmane.org/gmane.emacs.devel/86503

-- 
Bastien