Re: Proposal for collaborative maintenance of packages
Henrique de Moraes Holschuh <hmh@debian.org> writes:
> On Mon, 19 Dec 2005, Russ Allbery wrote:
>> This may not be the most popular opinion, particularly among fans of
>> distributed VCSes (and I do understand the merits), but wrapping your
>> mind around the distributed model isn't easy. I can explain to
>> sysadmins who have never used a VCS before but who have compiled
>> software and can work on Debian packages how to use Subversion, but
>> explaining bzr feels rather intimidating.
> " You have a central entity, be it a person (the project leader for
> example) or a bot, which has write access to the main repository.
> Everyone sends commits (working changesets) to this person/bot, for them
> to get merged to the main repository.
You just lost the people that I'm talking about. I can explain a
changeset, but merges are deep black magic that are extremely difficult to
understand except at a highly abstract level, and when using a distributed
VCS, they have to deal with merges all the time.
In a typical Debian package maintained in Subversion, they will *never*
have to merge except to import new upstream source, and if using something
like dpatch they don't even have to do it then and can appeal for help to
one of the experts on the team if the patches require fiddling to update.
And for many packages that don't require Debian-specific modifications,
you don't have to deal with either.
In Subversion, merges are a problem for large projects with lots of people
committing simultaneously. This is not the typical case for a Debian
package.
> Everyone has a local read-only copy of the main repository that they can
> use even while offline (which they sync to the main repository every now
> and then). Everyone has a local read-write repository that they use for
> ongoing work, even while offline. It is this work that, when deemed
> ready, is sent as a changeset for inclusion in the main repository. "
Speaking from direct personal experience, nothing confuses people more
about VCSs than having multiple repositories. This is another huge
stumbling block. People understand a central server and a single local
checkout that they make modifications in; once you add another local
repository, they immediately get very confused as to what goes where and
what order operations are supposed to be done in.
Yes, all of this stuff can and should be explained to people who are doing
serious software development, as understanding the distributed model is
quite valuable. But for people who are just casual helpers with Debian
packages that they're interested in, this stuff is very complex and
intimidating. Part of my day job is maintaining VCS systems for a group
of system administrators without a lot of software development experience,
and explaining CVS with a single shared central checkout (i.e., CVS in RCS
mode) is almost as much complexity as they want to handle on a regular
basis for something that isn't a core day-to-day part of their job.
> What IS difficult about it? It is exactly how the Linux kernel is
> managed, only they have various layers of "project leaders" and no bots.
Most people aren't going to be able to contribute to the Linux kernel, or
would even try beyond maybe sending a patch.
> Nobody in the system administrator, development or operation areas where
> I work would have too much difficulty grasping the basic idea, and it
> wouldn't take much time to explain the specifics (repository mirrors,
> etc).
> Whatever the issues of svn versus bzr are, difficulty of grasping the
> bzr way of doing things shouldn't be one of them.
Well, my personal experience says that you have an unusually VCS-friendly
set of people to work with, and that this is indeed a problem. But I
suppose I'm arguing from anecdote.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: