Use GitLab for all projects

If I'm reading this properly, I guess the main reason to do this would be to not be reliant on an external, commercial entity for such a critical piece of our project's future. Or is there anything in Gitlab's feature list that Github doesn't have? It might be easier to start from there, so we understand what we'd gain by incurring the ongoing costs you note down below (hardware, sysadmins...), which of course wouldn't be present with the Github option.

I send an email to gitlab, asking to chime in.

This feels like the right direction to me. Another plausible alternative is continue with the current drupal / git based infrastructure and enhance it to have pull requests and other desired features.

It feels right enough to me that I would contribute some resources to it, in terms of money and whatever time I have available (not much). Maybe there's something that could be done to prove the concept and move it down the road quickly.

What I have in mind is some sort of plan to:

1) Set up a gitlab that mirrors the d.o repos, or maybe just a few of the more popular modules
2) Have it pull some issues from the feeds so that it is actually useful for trying things
3) People won't actually try it in any meaningful way if work they do gets stranded there (with out manual effort). So we'd need something, maybe an extension of Dreditor or another greasemonkey script like it, that allow one-click generation of a patch & comment back to the home d.o issue.

It seems like a lot of work in glue code that will be eventually thrown away, but that's they way these types of integration projects go, I guess. Also, instead of the gitlab, I'd be willing to entertain an alternative of a Drupal Project with a lot of enhancements, but I fear that would not get us a good PoC very quickly.

When I say I'm willing to put in resources, I'm thinking from $1,000 to $5,000 and recruiting other money. Maybe one of the crowdsourcing systems out there could be used for it. I'm willing to put in that much, because I see Drupal as worth much more than that to my career, I see that it needs better infrastructure so that I can make money off of all those other contributors shared work, and I think the github solution won't cut it in the long term.

I am using GitHub for a group project developing a Drupal site, and I personally think that their issue tracker is terrible, compared to what we have now on drupal.org. Using the Github tracker would be a big step back in issue queue usability for my purposes. I can't even begin to elaborate on all of the features we take for granted in issue tracking that it doesn't have, because it's so basic that it has hardly any features.

There's a new - duplicate - proposal created at https://groups.drupal.org/node/314193, which should be merged into this one.

I am listening to this now and recommend having a listen. Gitlab has over 300 contributers so far and works very hard on growing their community.

http://pcasts.in/Ni32

We're working on a series of modules to integrate the API layer in Gitlab with Drupal using Services and WSData.

You can find the first of these here.

https://drupal.org/project/gitlab_webhooks

These could potentially help quite a bit in the process of switching to Gitlab. As we complete further API modules I'll post back.

I think gitlab would be a great solution, has this gone anywhere?

Edit: This is also something I would be very interested in working on.

We have other modules to publish as well. Just haven't gotten to it.

I'll see about getting those up for next week.

The current drupal.org workflow is such that if A posts a patch then B can post the next patch. This is simply impossible with github unless A gives permission to his/her repo to B which of course is not viable. Does gitlab allow for such "swarming"?

Out of the box, no, but since it is open source we can easily use the API (or custom code) to create a fork and give everybody (or everybody in that issue) access to it, or his/her own branch.

We can setup the 8.0.x branch to track Drupal and only allow merge requests to it, so once the issue is finished we have a clean patch.

AFAIK this is a just technical problem that can be solved

Is there a way that we could demo this or take some concrete action in this direction?

Sorry, my bad, I should have been more clear, I'm really all for this and have already given GitLab a try. Now I'm just wondering what steps we could take that would move this more toward taking a decision. Be it demoing that we can tie GitLab into a Drupal site, or actually working with the GitLab guys to discuss some of the features we need etc.

Well I know we can tie it to drupal for some of the workflow required. We built a tool for people to package and release private modules against both github and Gitlab.

http://dropfort.com

Not done yet but core functionality works.

The issue queue API we haven't played with yet but it's on the roadmap.

I know you can set the protected branch stuff through the API and create branches. The initial repo config you can't get through the api but I'm sure that's a feature can get made. Also making commits through the api doesn't work yet. But they recently added a lot of nice api calls fire dealing with tags and labels for issues.

Works pretty well actually.

Would anyone in this thread be interested in attending a DrupalCon BoF session?

I would love to get something more concrete started as well as enlist a group of people able to bring something like this to fruition.

I would recommend attending https://events.drupal.org/losangeles2015/sessions/issue-workspaces-bette... which should have an update for how the DA staff plans to tackle this.

Gitlab 8.0 added continuous integration support that would allow for distributed test bots etc. I'm starting a pilot to use it at my work place. If this is something we're thinking about doing, I'd loved to stay involved.

I've also just started looking into GitLab and enjoyed my experience so far. It seems to fit with the "get off the island" theme. It'd be great to see these two open source projects work together to make each other better!

A good primer on why this stuff is so difficult: https://www.drupal.org/drupalorg/blog/the-drupalorg-complexity

-mike

Looks like this idea has gained momentum: Technical Advisory Committee Update.