Since issue tracking stays on launchpad, I don't think the gitlab or github choice matters much as moving the repositories from one to the other without any issue tracking to worry about is a much smaller thing both in mindshare and technically.

I concur with suv that moving smaller repos first is a good idea for smoother learning curves. What about moving one small repo to github and another to gitlab so more eyeballs get to see both? Moving the small repos between the two is even simpler of course, so it could be a way to get a little more Pro/Con research done.

On a general regard I think this has good value for the Inkscape project - gaining a lot more developer traction - as bzr is, even though it hurts me to say as it was my first experience with dvcs systems, quite arcane these days. :(

On 6 Jan 2017 09:53, "Bryce Harrington" <bryce@...961...> wrote:
    "The time has come," the Walrus said,
    "To talk of many things:
    Of shoes — and ships — and sealing-wax—
    Of cabbages — and kings —
    And why the sea is boiling hot—

    And whether Inkscape should switch to gitlab or github or entirely other things."

At Hackfest 2015 we broached the topic of moving to git, and while
recognizing it as probably inevitable, decided to take care of a few
other things like switching to cmake first, and getting a release out
the door, and getting going with Gtk3 and C++-11.

That release is out the door, cmake is done, Gtk3 is landed in trunk,
C++-11 work is under way, and so I think it's time we start on tackling
git.

When we last visited this discussion, there was a consensus that yes we
should move to git, and that rather than self-hosting a plain git repo
(ala freedesktop), we would be better to look at an integrated platform
like github or gitlab.  But there was not a consensus as to which of
those two to pick.

So the task at hand is to discuss and deliberate the two and decide
which should be our focus.  Both have interesting pros and cons, and I
don't think the decision is clear cut.

Where should we go?

In github's favor is that it holds the greater mindshare.  Where we to
go with it we'd potentially tap into a larger community of developers,
which potentially could translate into a greater level of new
participation in the project.  github also seems like it's received a
greater amount of polish and has some feature advantages (github's CI
was seen as a huge pro last time we looked).

gitlab is an up-and-comer and is actively acquiring analogous features
to github.  A big pro for us is that gitlab is FOSS whereas gitlab is
free but proprietary.  With gitlab we'd also hold the option of
self-hosting, which might not matter or might be a huge advantage, it's
hard to say.

Both services provide broadly similar functionality and user
experiences.  The differences between them will be small compared with
the differences we'll be facing moving from bzr+launchpad.  Also,
migration from github to gitlab or vice versa if we change our minds
doesn't look like it'd be all that difficult.

Those may be the best two options but they're not the only ones we
have.  There's other services, and of course git can be used serverside
all on its own purely as commandline, or with cgit to provide a minimal
web service.


-- faqs -------------------------------------------------------------------

Why the need to move from bzr?  One of the reasons why we switched from
svn to bzr rather than git was because it was easier to learn; these
days so many people know git and don't know bzr (and probably don't care
to learn bzr) that this isn't quite such an advantage any more.  git is
also more actively maintained than bzr, and has a far bigger ecosystem
of tutorials, tools and services.  We also liked the integration between
bzr and the LP bug tracker -- we'll lose this, although github/gitlab
provide different integration opportunities that might compensate a bit.

What services would we move?  What we've discussed in the past is to
keep the migration limited to VCS, branch management, and code review.
The issue tracking in github/gitlab is quite different from what we've
grown accustomed to in LP so changing that might be too much disruption.
bzr->git is the main thing we're concerned with; transition of other
services can be handled on a case by case basis.

How would we undertake the transition?  suv made a good point today that
migration of smaller codebases first can be helpful so that the learning
curve can be digested in pieces rather than in one big go.  So perhaps
we should begin by moving some of our more peripheral bzr repos, then
maybe things like the website and then 2geom, and then do inkscape
last.

What about people who don't yet know git?  I suspect a lot of us either
already know git or have been working on learning it, that this isn't an
issue.  However, this transition is important enough I'd be willing to
propose to the board that we fund book purchases and/or other forms of
training for members that might need it.

When would the transition be done?  We've done some initial
experimentation already.  I would propose as soon as we have a strong
consensus for github or gitlab that we proceed with moving the board's
repository, inkscape-docs, and any other small / lesser-used
repositories still relevant to Inkscape.  Then second in perhaps a few
months migrate inkscape-web and 2geom over.  Once those are complete
then migrate the inkscape repository itself over, with the goal of
having the migration done.  I'd like to see the transition completed
prior to when we start getting heavily into the 0.93 release.

Let me know your thoughts, and help us drive towards a consensus for
github or gitlab.

Thanks,
Bryce


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1656...784...sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel