Re: source repository

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
>> Cc: Paul Pogonyshev <pogonyshev@gmx.net>,
>>     emacs-devel@gnu.org
>> Date: Wed, 04 Jul 2007 13:26:00 +0900
>> 
>> Didn't you just have a month of
>> acrimony over how to handle branching after the 22.1 release?
>
> People like talking, so they talked for a long time.  I didn't see any
> acrimony in that; I barely read the thread.
>
>> Don't you still completely lack any policy about how things will be
>> handled in the future except "Richard will decide, after hearing the
>> advice of other developers"?
>
> I don't see how a piece of software, any software, can resolve
> personal problems of this kind.

Actually, it is quite instructive how git does this in Linux kernel
development: most kernel developers maintain their own version of the
kernel and push around patches.  Some people collect and integrate a
variety of patches from different people according to their trust
metrics and have their own kernel series (like an
Andrew-Morton-kernel).  Kernel integrators integrate what they
consider useful patches.  Linus Torvalds is responsible for the
"canonical" kernel and merges hundreds of patches and patch sets per
week.  patch sets get signed off by people who consider them useful.
The actual act of merging, due to git keeping track of the conflicts
and diversions in branches and how they were resolved, is rather
painless for pretty much everybody.

At any point of time, there are literally hundreds of parallel
versions and branches from different people.  Consequently, there is
no discussion about what people might be allowed to merge when into
what branch: somebody wanting to test a particular functionality will
pull from the corresponding server of the particular developer, teach
his repository how to deal with conflicts in unrelated areas (likely
by backing out particular branches/change sets/whatever), and then be
able to track the functionalities he likes in his own branch.

So while git does not actually _resolve_ personal conflicts about what
we would like to have in the canonical Emacs, it allows postponing the
resolution for several parallel development lines almost indefinitely,
and everybody gets to play with everything he considers worth playing
with without having to have this centrally managed.  This obliterates
a whole bunch of pleading wars.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum