3 ms·

Why is it a barrier to adoption? Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. The integrati

Why is it a barrier to adoption? Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. The integration with our own tools will always be better, because we can do things that'd be hard with external tools, but if you want to use something else for anything, it'll work with GitLab.

gumby 10y ago
> Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. ... if you want to use something else for anything, it'll work with GitLab. If that's your intent then my statement is not operative, great. But your other public statements imply (to my reading) the opposite of what you say in your comment. For example, from the announcement: > We prefer to offer an integrated set of tools instead of a network of services or offering plugins for the following reasons: and some comments from your colleague theunquietone: > We believe in a single solution from idea to production. and when someone commented "Makes for a tough pitch at an established shop" he replied: "We hope to create tools and resources to make that pitch and migration easier." It's early days so you have time to clarify/refine your story.
- jobvandervoort 10y ago
  Our goal is to ship a single tool that will work for (almost) everyone. We believe that this will be a better experience and allow for deeper integration, besides cost, setup and maintenance advantages. That said, we don't expect to be able to replace every single tool one might use -such as internal tools-, therefore we make it possible to integrate with GitLab easily and have an API that covers everything. Examples of this are plenty. For instance, we build our commit status API to support our own CI system, but immediately also published the public API that allows any other CI to make use of this and offer similar integration in GitLab (in that case, you'll still have to switch between apps, which we believe can be better - hence our goal).
- lloeki 10y ago
  There are hooks, services, and OAuth2 support, as well as the API, which internally we leverage to extend GitLab or integrate with other products, kind of the way GitLab CI did before it was merged. Come to think of it, services like Travis CI could integrate with gitlab.com easily (if they wanted to do so).

gumby 10y ago

> Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. ... if you want to use something else for anything, it'll work with GitLab. If that's your intent then my statement is not operative, great. But your other public statements imply (to my reading) the opposite of what you say in your comment. For example, from the announcement: > We prefer to offer an integrated set of tools instead of a network of services or offering plugins for the following reasons: and some comments from your colleague theunquietone: > We believe in a single solution from idea to production. and when someone commented "Makes for a tough pitch at an established shop" he replied: "We hope to create tools and resources to make that pitch and migration easier." It's early days so you have time to clarify/refine your story.

jobvandervoort 10y ago
Our goal is to ship a single tool that will work for (almost) everyone. We believe that this will be a better experience and allow for deeper integration, besides cost, setup and maintenance advantages. That said, we don't expect to be able to replace every single tool one might use -such as internal tools-, therefore we make it possible to integrate with GitLab easily and have an API that covers everything. Examples of this are plenty. For instance, we build our commit status API to support our own CI system, but immediately also published the public API that allows any other CI to make use of this and offer similar integration in GitLab (in that case, you'll still have to switch between apps, which we believe can be better - hence our goal).
lloeki 10y ago
There are hooks, services, and OAuth2 support, as well as the API, which internally we leverage to extend GitLab or integrate with other products, kind of the way GitLab CI did before it was merged. Come to think of it, services like Travis CI could integrate with gitlab.com easily (if they wanted to do so).