4 ms·

I agree with you. To me it just sounds like people being entitled, expecting a service to never go down, ever. Shit happens and things go down. Design your proc

I agree with you. To me it just sounds like people being entitled, expecting a service to never go down, ever. Shit happens and things go down. Design your processes around that fact and have procedures lined up for when it does happen. However, saying "just get GitLab and deploy it to your own server" glosses over the huge time sink it is, especially for small companies that are already short-staffed, to maintain something like that. I sure as heck do not want to be responsible for keeping my GitLab server up. As you say, if you're writing an issue, put it in an editor issues.md file or something. If you're working on code, even better, just commit locally.

leesalminen 6y ago
Hosting Gitlab hasn’t been a huge time sink for me and I’m a one-person show who is conscious about my time. I set up automatic updates and haven’t SSH’d into that machine in about a year.
- bob1029 6y ago
  I agree that in many scenarios you will find that your approach is perfectly valid. For us, we have ~8 people that need to use the system all at the same time. We utilize issues very heavily (we are entering 5 figures), with lots of data-heavy QA content throughout (screenshots/videos/binaries/etc). Additionally, our customer environments are actually configured to talk directly to our GitHub repository for purposes of rebuilding themselves from source at update time. Because of the number of participants who are involved with our particular usage of GitHub, we find that a hosted solution with horizontal scalability and resilience to be an excellent fit. We have made the decision to make it Microsoft's problem to figure out how to eventually deal with 10k+ issues and 200+ employees/clients trying to hit the same host all at the same time. If we had decided to host our own GitHub/Lab server in our cloud environment, we would be having to constantly review the capacity of the IT systems. As we add employees and customers, the load we put on our source control solution will increase linearly. Additionally, because of the deploy-time approach, having a solution that is backed by someone else's network means that we don't have to worry about our private network being slammed by outside requests. Our total checkout is nearing a gigabyte, so you can see how this might scale poorly if we operated out of our own infrastructure. I almost feel like we are abusive of Microsoft's generosity considering the sheer amount of content we have throughout our organization's account. Every day I wonder when I am going to get some email demanding that we switch to a more expensive enterprise plan because of how we use the service. Maybe that day will never come. Even if it does, I will gladly shell out for the bigger contract.
  - zdragnar 6y ago
    I suppose it is different for you because you are all in private repositories but... have you seen github repos for very popular open source projects? Angular (the framework) alone has nearly 20k issues, the cli repo another 10k. React another 10k, golang 41k (35k closed, 6k open!) I have to imagine that you're not exactly a small fish, but also not making them sweat too much either.

leesalminen 6y ago

Hosting Gitlab hasn’t been a huge time sink for me and I’m a one-person show who is conscious about my time. I set up automatic updates and haven’t SSH’d into that machine in about a year.

bob1029 6y ago
I agree that in many scenarios you will find that your approach is perfectly valid. For us, we have ~8 people that need to use the system all at the same time. We utilize issues very heavily (we are entering 5 figures), with lots of data-heavy QA content throughout (screenshots/videos/binaries/etc). Additionally, our customer environments are actually configured to talk directly to our GitHub repository for purposes of rebuilding themselves from source at update time. Because of the number of participants who are involved with our particular usage of GitHub, we find that a hosted solution with horizontal scalability and resilience to be an excellent fit. We have made the decision to make it Microsoft's problem to figure out how to eventually deal with 10k+ issues and 200+ employees/clients trying to hit the same host all at the same time. If we had decided to host our own GitHub/Lab server in our cloud environment, we would be having to constantly review the capacity of the IT systems. As we add employees and customers, the load we put on our source control solution will increase linearly. Additionally, because of the deploy-time approach, having a solution that is backed by someone else's network means that we don't have to worry about our private network being slammed by outside requests. Our total checkout is nearing a gigabyte, so you can see how this might scale poorly if we operated out of our own infrastructure. I almost feel like we are abusive of Microsoft's generosity considering the sheer amount of content we have throughout our organization's account. Every day I wonder when I am going to get some email demanding that we switch to a more expensive enterprise plan because of how we use the service. Maybe that day will never come. Even if it does, I will gladly shell out for the bigger contract.
- zdragnar 6y ago
  I suppose it is different for you because you are all in private repositories but... have you seen github repos for very popular open source projects? Angular (the framework) alone has nearly 20k issues, the cli repo another 10k. React another 10k, golang 41k (35k closed, 6k open!) I have to imagine that you're not exactly a small fish, but also not making them sweat too much either.