Re: Git mirrors

[Jambunathan K]

"Stephen J. Turnbull" <address@hidden> writes:

> Vijay Lakshminarayanan writes:
>
>  > I think Óscar's questions have been answered.
>
> Not at all.  The "why" of the policy has not been touched by anybody,
> except by an appeal to authority and circular arguments.

The way it works in a social setup is someone complains, it is noted but
*not* acted upon *immediately*. Someone else complains sometime
later. It gets noted again but *nothing* happens. More people start
complaining at which point the contentious issue gets some primacy. The
policy may be reviewed and changes may be effected *going forward*.

(Note: "A complaint" in the eariler para could also be replaced with "a
leak in the system" or an "exeptional scenario or a situation".)

This is how incremental adjustments are made to policy/law etc once
there is a base working model. So in respect of incremental improvements
based on observing the system behaviour, a policy/law is not unlike
software.

I would summarize Oscar's arguments as follows - This is Oscar speaking
-

The *existing precedent* of a GNU project encouraging a sister project
(by using it) solely based on the sister project's license criterion (or
ideological affirmations) has implications for adoption of the project
in question. Has this consideration been factored in to while the
current precedent was set in motion. If not - which I am confident is
the case - can this situation be changed? Emacs is a mature and already
a popular project so the impact on "adoption" does not arise. What if
the project in question is a *totally* new or the "in works" GNU project
- arguably a project labelled as "high priority". Will it's adoption
suffer merely because it went with a lesser known and not so popular
VCS.

> I beg you to look harder.  Any number of good things will come of it,
> though not necessarily directly beneficial to Emacs.  In particular,
> *you* learned something, but there are other benefits, including a
> better understanding of a central tool in the workflow, and off-list
> negotiations to better promote the GNU Project.

IMO, the reason Oscar continued to exchange mails was this: an implicit
assumption that the existing system will be overthrown or replaced as
soon as his request/warning is registered. This is not how things
work. 

If something is not "utterly" broken, it is not going to be fixed
immediately or fixed at all. bzr isn't broken and it would be naive of
anyone to expect that it will be replaced. 

The reason others - the experienced ones, such as Stephen or others -
continued to exchange mails was to throw some weight around the
argument, to refine their own understanding or to share or discover new
facts or simply to help Oscar articulate his ideas better or to stress
test his arguments to see whether it withstands some onslaught.

On the whole, the discussion was a healthy one even though it veered a
bit.

Jambunathan K.
--