jobvandervoort

We also continuously iterate on the compensation calculator, often because of feedback from applicants and employees.

Read about the ideas behind it here: https://about.gitlab.com/handbook/people-operations/global-c...

We have no plans to support Mercurial, unfortunately.

They changed this for the iPhone X: you press the lock and one of the volume buttons at the same time.

Did you try turning on the new navigation? [0] Profile picture in navbar -> Turn on new navigation

[0]: https://about.gitlab.com/2017/07/22/gitlab-9-4-released/#new...

Filipa, one of our frontend engineers, recently gave a talk at VueConf about our move to Vue.js: https://www.youtube.com/watch?v=-69tKcl1oTE

Same here, we loved it. Played it together with my partner.

We immediately ordered a second scenario after completing the first. The price was worth it for us.

> I want something that keeps an encrypted file that I can put in dropbox

FWIW You can do this with 1Password. Preferences > Sync > Sync with Dropbox

We don't maintain our own, but there are a number of GitLab API CLI tools and wrappers. Have a look here: https://about.gitlab.com/applications/#cli-clients

Apologies. I'm pushing an update that should significantly reduce image size.

You can consider using mirroring with GitLab to have everything in a single GitLab instance: https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...

One of the high level goals I set for this year is scaling up to projects that consist of more than a single repository.

That means CI that spans multiple projects [0], higher abstraction of issue management [1], formal relationships between issues [2] and more.

Having a global wiki or higher level wiki should also be part of that [3], I think.

[0]: https://gitlab.com/gitlab-org/gitlab-ee/issues/933

[1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/928

[2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058

[3]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4037

Glad to hear that. You can also import your projects directly (everything will be copied over).

We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.

Thanks!

We're working on it! We were holding off until subgroups shipped so we can make sure group-level boards work well with it. It's on the shortlist for one of the next releases. Our PM for this, Victor, might provide more detail here later.

Issue for this: https://gitlab.com/gitlab-org/gitlab-ee/issues/928

No, but we're hoping to work together with the community to make all these features available on all major platforms [0].

One thing that we're seeing is that most schedulers are moving towards supporting Kubernetes, which goes a long way in making this work there. Right now we support Kubernetes through Google Container Engine or via Openshift.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20199

It seems the issue is on the wrong issue tracker. Our omnibus lead Marin will make sure that it lands in the right place and gets some attention (see the comment from ZJ).

Edit: more info in the issue you've posted.

It's Grafana [0], backed by Prometheus [1].

[0]: https://grafana.com/

[1]: https://prometheus.io/

That's correct. We don't have any offices. You're free to work from home, a coworking space (by our expense) or anywhere else, but there's no GitLab office.

We have a 'headquarters', which is also where Sytse (CEO) lives, where there are a number of desks available for special occasions, but no one is ever required to work from a particular place.

You can find some public monitoring regarding CI on GitLab.com here [0].

I agree that we should have some status on CI as well, made an issue [1].

[0]: http://monitor.gitlab.net/dashboard/db/ci

[1]: https://gitlab.com/gitlab-com/infrastructure/issues/1360

> I've used Gitlab CI before and I do like it, but TravisCI allowed for some granular control that Gitlab CI does not have (or that I am doing wrong) - for example, ability to run specific tests in case of pull/merge requests (TrasisCI has an environment variable for it).

Ah interesting! You can't do this now with GitLab, but we're working on supporting merge requests as special cases [0].

> As for other projects - the most important one for me was clubhouse.io (Gitlab Issues is great but just not as good as clubhouse.io)

Clubhouse sure looks nice! GitLab Issues is getting better every release and in 9.0 (March 22nd), we have some big changes for Issue Boards.

I've asked our PM on Issues (Victor) to check out Clubhouse and hopefully we can convince them to integrate with us in some way.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

We're working very hard on making GitLab.com much faster. Right now, it's measurably (and more importantly: measured [0]) faster than it was a month ago.

If you would like to follow progress you can dive into it all here [1]. One of the spearpoints is Gitaly, which should significantly improve git access.

[0]: http://monitor.gitlab.net/dashboard/db/fleet-overview?from=n...

[1]: https://gitlab.com/gitlab-com/infrastructure/issues/947

Let us know what projects you miss seeing integrated with GitLab and we'll try our best to convince them, help them in any way to make sure it happens!

As other point out, you should be able to use GitLab CI instead of Travis, they configure very similarly. That said, I'd welcome them integrating fully with us as well.

That's great to hear.

We're working on making it easier to see what is happening in merge requests. It's the intersection of much of GitLab's power [0]. I see some thing in the issue that might help your case, but I'm also sharing your comment there. If you have more comments, please feel free to leave them in that issue or to me directly.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/25424

> The problem, it turned out, was not with Marcus Munafo's science, but with the way the scientific literature had been "tidied up" to present a much clearer, more robust outcome.

I've seen this time and time again while working in neuroscience and hearing the same from friends that are still in those fields.

Data is often thoroughly massaged, outliers left out of reporting and methods tuned to confirm, rather than falsify certain outcomes. It's very demotivating as a PhD student to see very significant results, but when you perform the same study, you don't find reality to be as black and white as published papers.

On this note, the majority of papers is still about reporting significant results, leading to several labs chasing dead ends, as none of them can publish "negative" results.

Great to hear; It has taken us a bit longer than we wanted, but we're happy it's here. Let us know if there are any further improvements we can make.

To add to this, you can use any static website generator with GitLab, here's a simple getting started: https://about.gitlab.com/2016/04/07/gitlab-pages-setup/

I'm a firm believer that with improving the tools (in my case- GitLab), CMS will become a thing of the past and static pages will be as accessible, yet more powerful, faster and more collaborative.

Talking about this commit: https://github.com/golang/go/commit/faf882d1d427e8c8a9a1be00...

Performance is really important, especially to user experience. We want GitLab to be fast, independent of the scale it's used at.

Right now, GitLab is fast and snappy for people that self-host it, but GitLab.com is not and we're not happy with that [0]. Making our front end performant is part of that and I'm happy our engineers have been working hard on that.

We have been using Prometheus extensively to monitor speed of transactions on the backend and I'm seeing a strong push to more monitoring to front end monitoring as well (I owe you a link here).

[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59

I'm not sure why anyone would say GitLab CI is slow. You run it on any machine you want, so it's fully dependent on that.

The script that authenticates and picks up the job is a small Golang app. That's all. GitLab executes CI jobs immediately.

See the architecture and related links here: https://about.gitlab.com/gitlab-ci/#architecture

We had the call live with all engineers and asked if everyone was okay with streaming this.

Someone not involved with helping fixing the problem set up the stream from their home, while we continued work as normal.

I think the overall spirit was that it was comfortable to do it like this. Note that no one was required to work like this and we'd happily stopped streaming if anyone would have any problems with it.

Part of the stream is here: https://www.youtube.com/watch?v=nc0hPGerSd4

Not sure if we'll be able to get the full 8+ hours up.