web2004 / sytse.com wrote:
> Eric Wong <normalperson / yhbt.net> wrote:
> >  The main site's Terms of Service (or any ToS) is still a problem
> >  for me.  Currently there is no ToS at all on our Redmine instance
> >  and registration is completely non-intuitive on GitLab w/o JS.

> 1. Is this about the terms of service for GitLab.com or something
> else? Since I think a self hosted GitLab instance is proposed I think
> there are no ToS.

OK for the proposed instance.  But if we find a problem with the hosted
instance and want to report the problem to GitLab itself, the reporter
would still have to deal with the ToS of GitLab.com

A bigger problem is none of these centralized messaging systems have any
interopability with each other.  Different Redmine/GitLab instances
cannot talk to each other; and Redmine instances can't talk to GitLab
instances, etc.  Bugs do cross project boundaries occasionally...

Plain-text email is still the only interoperable way to communicate.
Debian's BTS actually gets this right and interoperates well with
existing mailing lists.  From my limited experience, RT does as well.

> 2. If better non-javascript functionality is needed for the conversion
> to happen we would be happy to add that.

For one, the registration page I noted earlier only shows a bunch
of unlabeled input boxes on w3m (which has no JS or CSS support).

Does GitLab have mailing list integration?  Fwiw, I would not have
bothered contributing to Ruby if we did not have ruby-core mailing list
integration with Redmine (but I'm only an occasional contributor to
Ruby).

> 3. If GitLab Inc. is acquired by another company (which is unlikely)
> GitLab the project will still continue. It is in use by more than
> 100,000 organizations and has over 800 contributors and is MIT
> licensed.

It's likely the Gitorious guys were thinking the same a few years ago :)

Really, I remain unconvinced GitLab is any better than Redmine.

What I can comfortably say is git is better than SVN in most aspects:

* robustness/data integrity
* disconnected operation
* speed
* scriptability with a stable plumbing interface
* ease-of-contributing (open-to-everyone mailing list)

Of course git likely loses in terms of usability and learning curve[1],
and maybe still doesn't work as well on non-Free OSes.



[1] Side note: I recommend anybody new to git to learn the
    blob/tree/commit data relationships with the plumbing, first;
    but maybe that's just me.