[qTox-dev] Dependence on proprietary Github & move to GitLab

[Zetok Zalbavar]

qTox as a project has a slight dependency on proprietary github.
Sadly, moving to GitLab is not an option yet, since:

1. There's no OSX worker provided by gitlab.com.  We would either need
to provide our own, or drop it entirely.
1.1. The need for OSX stuff can be nullified by someone willing to do
the OSX dance and make sure that qTox compiles & works there.
2. There are no IRC notifications that would just work™.  It is possible
to have IRC notifications with GitLab, but that requires running IRC
part of the software on own server, and lots(?) of manual configuration.
This is far from optimal.  Made an issue[1] for it, we'll see how it goes.
3. GitLab is really bad when it comes to its build-in search function
for projects. I.e. if someone just visited gitlab.com and wanted to
search for qTox, they most likely wouldn't be able to find it. At all,
among hundreds of forks that are treated equally.
4. Importing from github is buggy.  This most likely will be fixed at
some point, and it would seem that GitLab team is actively interested in
making sure that migration will work, and if it comes to things, they
most likely will be able to help us move, and fix the bugs in GitLab
during the process.

Those were negative points that will take at least **a lot** of time to
get fixed. There's also the unfamiliar UI, but that's something one can
deal with, since this requires only a bit of time to get used to.


Now, the positive side:

1. No fear of takedown for no reason.  github has its history of taking
down projects it doesn't like.  Because reasons.  And no, there's no way
to get things back – stuff like issues, pull requests, forks and what
not are gone when github decides that this time of the week a project
needs to be nuked.  There's no such bullshit on GitLab.  And even if
there was, look at point 2.
2. Data freedom.  If GitLab decides one day to "pack the bags and go
home" we still have our data – issues, merge requests and what not
associated with the project, since GitLab does provide an **export
project** functionality.  With it, project can be easily imported in our
own GitLab instance very quickly, and with little to no disruption in
workflow.
3. Commit message format verification build-in.  And it's way better
than the work-around we have now.
4. Other things.  There's really a lot of them, ranging from
moral/ethical to purely technical.


There's also thing with code review – build-in GitLab code review
possibly can replace reviewable; this needs to be verified.



The aim of this post is to gather feedback about other requirements that
would need to be satisfied to move to GitLab, and how important given
requirement is.

The move to GitLab will happen, be it sooner or later, so it's a matter
of being prepared for it, and making an informed decision on when the
move should happen.


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/22178
-- 

Kind regards,
Zetok Zalbavar
----
tox:29AE62F95C56063D833024B1CB5C2140DC4AEB94A80FF4596CACC460D7BAA062E0A92C3424A0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tox.chat/pipermail/qtox-dev/attachments/20160914/9a4ff635/attachment.sig>