Re: bzr repository ready?

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Sat, 28 Nov 2009 04:06:40 +0900
> 
> Eli Zaretskii writes:
> 
>  > I personally would regret [a document that advocates a particular
>  > workflow to start from].  I think I'm grown-up enough to not have
>  > me spoon-fed.  Give me the information and let me decide myself
>  > what's best for me, even if I make some mistakes on the way.
> 
> But BzrForEmacsDevs is not about what's best for you.  Figuring *that*
> out is your privilege, and your problem.

You seem to interpret the ``I personally'' thing too literally.  I
wrote that in the personal style, but it should have been clear that I
thought others will feel that way as well: that patronizing us is not
the way to go.  Evidently, it wasn't clear enough, sorry.

> BzrForEmacsDevs is about designing a recommended starter workflow
> that the majority of Emacs hackers can adopt without worrying too
> much, while avoiding the common mistakes that make life a lot less
> pleasant for the other people accessing the repository.

It remains to be proven whether a workflow exists that would be good
for ``the majority of Emacs hackers''.  The wiki page already talks
about several kinds of hackers, and suggest different workflows for
each one of them.

More importantly, what little I've read about dVCS practices suggests
that the best workflow depends heavily on a combination of factors,
such as the number and typical activity levels of core developers, the
amount of overlap in the areas where they and their downstream hackers
develop, the explicit division of maintainership between the core
developers, etc.  I think all these factors change from project to
project, so when a large project such as Emacs switches to a dVCS, it
will take time for us to figure out all these factors and find the
right set of workflows.

So I wouldn't worry too much if several workflows were described on
the wiki, and not a single one, since trying to have a single one
might simply yield a wrong one.

If we worry about a starter workflow, then that can be gleaned from
the Bazaar's getting started tutorial.  It's pretty clear, and
therefore it's easy to get started.

The question that bothers me is what's next.  We didn't decide to
switch to Bazaar just to do the same as we did with CVS.  Therefore,
the issue of the workflows for the Emacs project as a whole and for
the individual developers _should_be_ an important one, not something
swept under the rug because it's deemed ``confusing''.  Nothing is
confusing if it's clearly explained, especially with the audience we
have here: experienced code developers who know one or two things
about data structures and algorithms, so describing some of the inner
workings of Bazaar that underlie some of the recommendations for and
against workflows should not be hard.

Yes, it would make the wiki page substantially longer, but we could
organize it in a way that people who are impatient to get to the
bottom line will have it.

> See http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/0539.html
> for some of Linus's wisdom on the social aspects of workflows.  That
> really rings true for me, but do you have any idea what he's talking
> about?

I think I do, although I don't necessarily see how that's related to
the present discussion.  Perhaps you assume that I want the best
workflow for me at the expense of others.  If so, that's false, and if
what I wrote could somehow be interpreted to that effect, I'm sorry.

What I really meant was that describing several possible workflows
with their pros and cons would enable a discussion among developers
that would yield the set of recommended workflows (I don't believe
there's only one) that would serve well both the individual developers
and their peers, and the project as a whole.

>  > What is ``full dVCS practice''?  Can you describe it (or was it
>  > already described in this thread)?
> 
> Heh.  Ask any three developers, you'll get four opinions. :-)

What's yours, if I may ask?