6 ms·

It's not about being larger, it's about doing changes. GitHub used to be pretty stable before, when they didn't really do any (user facing) changes. It stood st

It's not about being larger, it's about doing changes. GitHub used to be pretty stable before, when they didn't really do any (user facing) changes. It stood still in terms of features, but was also pretty stable overall. Compared to GitHub, how often does your Gitea instance go through code changes? How many major features have been switched on in that instance during the past year without any hiccups?

freedomben 5y ago
I tried to look at the Gitea repo to see how fast they get commits, but github is 500ing :-( https://github.com/go-gitea/gitea https://github.com/go-gitea/gitea
- chockchocschoir 5y ago
  Rest assure, a open source project with ~100 contributors (whereas maybe 10% regularly contributes) has less activity and changes than a multi-international company focusing a SaaS with "1000 to 5000" employees worldwide.
  - judge2020 5y ago
    For perspective, GitHub has 4,000 employees who list them as their employer on LinkedIn and GitLab has 1,700.
Deukhoofd 5y ago
I run Gitea myself as well. I generally throw in a new release once a month or so, never had any real hiccups.
- rolph 5y ago
  it sounds like you dont make code changes unless they are required for function.
  - Deukhoofd 5y ago
    Also for security reasons, and because some features are nice to have. But you're right in that I'm definitely not randomly updating sometimes. When I do update I basically just back up the database, throw in a new Gitea binary, and restart the service. As the releases have been fairly well tested in general, this hasn't given me issues so far.
- chockchocschoir 5y ago
  Again, how much it actually change across those releases? GitHub most likely are going through more changes on a weekly basis (if not daily) than what Gitea does on a monthly basis.
  - Deukhoofd 5y ago
    The major releases generally change quite a lot in one go, for example: https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-released/ https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-releas... https://blog.gitea.io/2021/08/gitea-1.15.0-is-released/ https://blog.gitea.io/2021/08/gitea-1.15.0-is-released/ But I'm sure Github changes a lot more. However, the question is if those changes are worth the instability. For my workflow I just want my repos to be accessible, have my source, issues, and wiki accessible, and of course my basic git operations working. If that core functionality is actually not working at times, I'd definitely consider changing the git provider.
dogleash 5y ago
GitHub's feature churn is irrelevant to the comparison unless those features are used in parent poster's workflow.
- chockchocschoir 5y ago
  Really? No, comparing the uptime of two services (actually, one service and one open source self-hosted service) it's relevant to consider _why_ one would have more downtime than another, even if they don't use those features. Even if the parent posters workflow doesn't use the new/deprecated features, they will still be affected by the downtime GitHub have monthly.
  - Nextgrid 5y ago
    I don't think anyone is overlooking the reasons why one might have more downtime than the other. The problem is that ultimately the downtime itself matters and not the reason, and if you don't need any of the features that GitHub offers, then the self-hosted route is a better option.
    - falcolas 5y ago
      > if you don't need any of the features that GitHub offers In particular, all of the new features whose addition causes instability.
      - Nextgrid 5y ago
        I think it's the development process (as in moving things around and potentially introducing bugs) than the new features per-se.
        falcolas 5y ago
        With all due respect to the developers, it would not speak well for GitHub if they can't maintain stability while refactoring. There's a lot of testing processes and CI processes explicitly around making those actions safe. New features breaking is a lot more understandable - even expected - than regressions and refactoring failures.
newswasboring 5y ago
An infrastructure company focusing on feature churn just sounds wrong.
- woah 5y ago
  What? Github is a social networking company.
  - newswasboring 5y ago
    I'm a bit dumb about these things on text, but did you drop an "/s" somewhere? I understand it has sort of a social networking layer on top, but that is not its main function right? This would be like calling a calculator app a social networking app because it allows me to share my results :D.
    - chockchocschoir 5y ago
      GitHub has always branded itself as a "social collaboration platform" rather than anything else (well, first "git hosting" but secondly the social stuff). Here is a early version of their landing page from 2008 (the year they launched): https://web.archive.org/web/20081111061111/http://github.com/ https://web.archive.org/web/20081111061111/http://github.com... Notice the logo says "Social code hosting" and the messaging of the page is mostly around popular repositories, collaborative features and other social elements.

freedomben 5y ago

I tried to look at the Gitea repo to see how fast they get commits, but github is 500ing :-( https://github.com/go-gitea/gitea https://github.com/go-gitea/gitea

chockchocschoir 5y ago
Rest assure, a open source project with ~100 contributors (whereas maybe 10% regularly contributes) has less activity and changes than a multi-international company focusing a SaaS with "1000 to 5000" employees worldwide.
- judge2020 5y ago
  For perspective, GitHub has 4,000 employees who list them as their employer on LinkedIn and GitLab has 1,700.

Deukhoofd 5y ago

I run Gitea myself as well. I generally throw in a new release once a month or so, never had any real hiccups.

rolph 5y ago
it sounds like you dont make code changes unless they are required for function.
- Deukhoofd 5y ago
  Also for security reasons, and because some features are nice to have. But you're right in that I'm definitely not randomly updating sometimes. When I do update I basically just back up the database, throw in a new Gitea binary, and restart the service. As the releases have been fairly well tested in general, this hasn't given me issues so far.
chockchocschoir 5y ago
Again, how much it actually change across those releases? GitHub most likely are going through more changes on a weekly basis (if not daily) than what Gitea does on a monthly basis.
- Deukhoofd 5y ago
  The major releases generally change quite a lot in one go, for example: https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-released/ https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-releas... https://blog.gitea.io/2021/08/gitea-1.15.0-is-released/ https://blog.gitea.io/2021/08/gitea-1.15.0-is-released/ But I'm sure Github changes a lot more. However, the question is if those changes are worth the instability. For my workflow I just want my repos to be accessible, have my source, issues, and wiki accessible, and of course my basic git operations working. If that core functionality is actually not working at times, I'd definitely consider changing the git provider.

dogleash 5y ago

GitHub's feature churn is irrelevant to the comparison unless those features are used in parent poster's workflow.

chockchocschoir 5y ago
Really? No, comparing the uptime of two services (actually, one service and one open source self-hosted service) it's relevant to consider _why_ one would have more downtime than another, even if they don't use those features. Even if the parent posters workflow doesn't use the new/deprecated features, they will still be affected by the downtime GitHub have monthly.
- Nextgrid 5y ago
  I don't think anyone is overlooking the reasons why one might have more downtime than the other. The problem is that ultimately the downtime itself matters and not the reason, and if you don't need any of the features that GitHub offers, then the self-hosted route is a better option.
  - falcolas 5y ago
    > if you don't need any of the features that GitHub offers In particular, all of the new features whose addition causes instability.
    - Nextgrid 5y ago
      I think it's the development process (as in moving things around and potentially introducing bugs) than the new features per-se.
      - falcolas 5y ago
        With all due respect to the developers, it would not speak well for GitHub if they can't maintain stability while refactoring. There's a lot of testing processes and CI processes explicitly around making those actions safe. New features breaking is a lot more understandable - even expected - than regressions and refactoring failures.

newswasboring 5y ago

An infrastructure company focusing on feature churn just sounds wrong.

woah 5y ago
What? Github is a social networking company.
- newswasboring 5y ago
  I'm a bit dumb about these things on text, but did you drop an "/s" somewhere? I understand it has sort of a social networking layer on top, but that is not its main function right? This would be like calling a calculator app a social networking app because it allows me to share my results :D.
  - chockchocschoir 5y ago
    GitHub has always branded itself as a "social collaboration platform" rather than anything else (well, first "git hosting" but secondly the social stuff). Here is a early version of their landing page from 2008 (the year they launched): https://web.archive.org/web/20081111061111/http://github.com/ https://web.archive.org/web/20081111061111/http://github.com... Notice the logo says "Social code hosting" and the messaging of the page is mostly around popular repositories, collaborative features and other social elements.