connorshea

10 ms·

61.
by connorshea 10y ago
GitLab Pages [0] is pretty good for static websites IMO, you can use GitLab CI to build more complex sites as well [1]. Disclosure: I work for GitLab [0]: pages.gitlab.io [1]: https://about.gitlab.com/2016/12/07&#x
62.
by connorshea 10y ago
She's referring to issues in the backup process specifically, not in the company culture (which IMO is pretty good).
63.
by connorshea 10y ago
I didn't know Zapier was a fully remote company, that's awesome :) I pretty much agree with your thoughts about over-communicating, it's super important and we've run into exactly the same things, where people aren'
64.
by connorshea 10y ago
It should be noted that Gogs was recently forked to Gitea due to disagreements about the management style of Gogs as an open source project. See https://blog.gitea.io/2016/12/welcome-to-gitea/
65.
by connorshea 10y ago
JRuby isn't an option for us because we use too many gems, many of which have compatibility issues with JRuby's implementation of Ruby. This is especially a problem for gems with C extensions. I think Truffle is the most interesti
66.
by connorshea 10y ago
Once Rails 5.1 comes out and we upgrade to it we'll probably switch to Webpacker. It was an awesome development in the Rails ecosystem and really verified our investment into Webpack.
67.
by connorshea 10y ago
We didn't go with TypeScript because we were burnt by CoffeeScript before. People don't know TypeScript or CoffeeScript nearly as much as they know vanilla/ES6 JavaScript. It's easier to hire for and easier to get contri
68.
by connorshea 10y ago
Actually we just removed Turbolinks the other day, so this is a non-problem. :)
69.
by connorshea 10y ago
The Vue docs are seriously amazing, I couldn't rap my head around React fully because its docs just weren't very good (though they've improved them since I last tried).
70.
by connorshea 10y ago
Sorry for the bad experience :( We're constantly working on improving GitLab's performance, and we have a bunch of issues open for performance fixes/improvements we'll be doing for the upcoming 9.0 release: https:/
71.
by connorshea 10y ago
Even better, have a Chaos Monkey do it ;)
72.
by connorshea 10y ago
Glad to hear others will learn from our mistakes, we certainly are :)
73.
by connorshea 10y ago
It'll definitely be a priority now!
74.
by connorshea 10y ago
Yup, it's never the fault of a person, always of the system. Once we get this resolved we'll definitely look at ways to prevent anything like it in the future.
75.
by connorshea 10y ago
Danger hosts their website with GitLab Pages[0], iTerm hosts their issue tracker there[1], the game Xonotic is hosted on GitLab.com[2], and then VLC[3] and GNU[4] both have their own instances of GitLab. [0]: https://gitlab.com&#
76.
by connorshea 10y ago
We've spent quite a bit of time this year improving performance, GitLab.com is still slower than it should be but it's a lot better now than it was in January. Self-hosted instances that meet the recommended specs are already fair
77.
by connorshea 10y ago
>I'm curious how you guys build features for EE. Is it a completely separate Rails project you handle manually to keep base features in sync with the community edition? It's the same codebase with some additional code. Every fe
78.
by connorshea 10y ago
I'm not sure I understand why you're under the impression that you need a 3rd party application for that, as far as I know it's possible with just GitLab and Mattermost. If there are any confusing docs we need to improve I&#x
79.
by connorshea 10y ago
Thanks for the honest feedback, it's genuinely useful for improving the product. Out of curiosity, why use the Docker image over our Omnibus package? Omnibus is generally what we recommend, but if that's not good enough we'd
80.
by connorshea 10y ago
We'd strongly recommend that you open an issue to discuss it first, but yeah, of course they are! :)
81.
by connorshea 10y ago
Are you using GitLab.com or hosting it yourself? We're working on improving GitLab.com, but self-hosting GitLab should be pretty fast in most circumstances. As for the interface, we're working on improving the design of the produc
82.
by connorshea 10y ago
The comprehensive API helps, though that can theoretically be limited if a ton of people try to migrate.
83.
by connorshea 10y ago
I'm a GitLab Community Advocate, so I'm biased, but off the top of my head: - Performance, we're working on improving this for GitLab.com but right now it's slower than we'd like. If you run your own instance it&#x2
84.
by connorshea 10y ago
GitLab does have it already: https://docs.gitlab.com/ce/user/project/merge_requests/resol...
85.
by connorshea 10y ago
We hope so too ;)
86.
by connorshea 10y ago
No plans to support Mercurial, it would complicate development a lot. Plus it would be a second-rate citizen and that wouldn't be very nice of us.
87.
by connorshea 10y ago
Yeah, we're working on improving the search by moving to Algolia for it[1], the current system doesn't work as well as we'd like. The point was at least partially to share a workflow I hadn't been able to find any other
88.
by connorshea 10y ago
I'd be happy to answer any questions anyone has (about the post or anything else) :)
89.
Building a New GitLab Docs Site with Nanoc, GitLab CI, and GitLab Pages(about.gitlab.com)
26 points by connorshea 10y ago|5 comments
90.
by connorshea 10y ago
No problem, the thread is pretty long, and it's not necessarily easy to tell without understanding how our blog post process works. :)

More ›