1. 13

Gitea is the fork of Gogs, a super-lightweight Git hosting tool written in Go. I’m linking to this particular release because part of the promise of Gitea was that they were going to move a lot faster than Gogs, implementing many features and pull requests that Gogs' author had refused to implement, and I think this release clearly demonstrates they’re delivering on that promise.

    1. 3

      Somewhat random aside: turning on disqus comments for your docs site is a terrible idea. If you make it possible for people to abuse random pages as a support forum… it’s going to happen.

      1. 2

        I agree, having issues/support questions fragmented, can be a huge big deal breaker. Just imagine you’re running into an issue so you:

        search via. web search engines, check out the project’s issue tracker, look for recent tweets mentioning the project, skimm through comment sections of the blog, link aggregators, reddit, mailinglist archives, IRC logs, …

        So it’s in reality not only a comment section only issue, but a problem of information spreading across multiple sources. And how could you mitigate this? Create a “Support Statement”. Link to this support statement in all of your communication channels, kindly point out the statement if ignored and start moderating in worst case.

        Why I don’t want to have comment sections removed?

        Projects often provide some outdated information on their blogs. Including a comment section can encourage others to contribute with more up to date details. This then can help people on a lost track to figure out where to continue searching, reducing their effort and used time for each problem. Other side, if I run into an issue, thing something can done be differently or want to add something helpful - I comment and hope, someone will find my informations usable.

        In general, comment sections often provide helpful additional details. The scope of a single blogposting is always limited. Comments are a way of expanding such scope and this without having many trade offs.

        Side note: Gitlab is also having a comment section below their release notes and before upgrading I, more than once, found some helpful informations in there.

        Final thoughts

        I think as long as you stay with this ‘specific traditional way’ of providing informations, a comment section can be a good thing and should not just be shut down. It’s hard to come up with a different solutions that other people will actually use. I’d really like to see different approaches, but I don’t think you’ll suddenly figure out different ones, just by reducing the quality of status quo.

        Maybe it would be cool to have an auto-generated list of issues, summarizing all issues introduced with each release. Thank’s for reading.

        Edit: Rephrasing Gitlb sentence a bit (still not perfect).

    2. 2

      I find it somewhat telling that they aren’t dogfooding.

      If your project is all about hosting code repos and you don’t host your own code, something is wrong.

      1. 15

        If they were doing that “just cuz,” I’d agree with you, but the fact they have a thorough list of what they need to self-host, plus my own experiences working on Kiln, make me give them the benefit of the doubt.

        When I was working on Kiln, I was constantly pushing for self-hosting, way before the product was “ready,” for the exact reason you’re pointing out: we should put our money where our mouth was. And I won that fight pretty early, when we were right around the level of features Gitea 1.0 or 1.1, albeit with a less-polished UI. My theory was that going to the product even before we hit our minimal internal viable product (MIVP?) would help us shape those features, and that at any rate using Kiln couldn’t be worse than using bare Mercurial hosting.

        Oh boy was I wrong. What actually happened was that we implemented the shittiest possible version of the missing features almost immediately so that we could get work done. I’m talking hybrid Perl/Smalltalk services running on my personal desktop busy-polling the Kiln prototype installation to generate RSS and email notifications based on hand-written rules I modified when people asked me to. I’m talking having to take time out from getting to feature completion to write a Mercurial history import rebuilder that we never would’ve had to build if we’d waited for our schema to stabilize. I’m talking shoving out a clunky ASP.NET adapter that buffered the whole Mercurial request in RAM before even starting to process the thing because it at least worked and I didn’t have time to fully wrap my head around writing a proper ISAPI plugin.

        The result was we got distracted from actually making Kiln work and probably lost a month doing one-off POS versions of features we knew we’d need to build properly anyway, plus damaged a bunch of internal goodwill at Fog Creek on the quality of Kiln, plus hurt our own morale by associating our own product with being incomplete and annoying. I am not proud of that decision and would not repeat it.

        We can argue a bit over some of the things Gitea throws in their MIVP bucket (becoming an OAuth provider would definitely be nice, but you could always just make an extra account and give your CI explicit login permissions), but a few key ones, like line comments on pull requests or improving the notification system, have really, really strong echoes of the situation I saw on Kiln. They’re targeting getting to self-hosting, and they know why they don’t want to go there yet. I support them waiting.

        That said, I’m happily using Gitea myself and have been really pleased with its stability, UI, and upgrade story. Doing viable backups is also really easy, and abandoning it for another Git hosting option would be really, really easy, because Git. So don’t use it if you need the same features the Gitea team does, but if it’s just a light install on a non-review-heavy workload, I’d at least give it a look.

      2. 2

        Infrastructure is money and pain; I don’t blame them at all for using a platform that’s ready to go. Plus it seems weird to complain that they should put more of their time and money into the project?

        1. 3

          Luckily we got some sponsoring, so our time is the “only” investment we have to give.

        2. 2

          I don’t know. How much effort and expense is involved in standing up a $10 linode for hosting?

          I mean, I understand what you’re saying, but at the same time, this seems to be solidly within their target audience. If hosting your own gogs/gitea is too hard, how well do you understand your audience?

        3. 1

          Right from their own site: Hosted and sponsored by DigitalOcean

          So, for the “pain” part of it: if they’re not capable of organising someone to setup their own software on a server, I’m not sure I have much faith in their ability to write said software, or their goals for it.

          1. 3

            It’s not a pain to host or setup, we are providing all the infrastructure on sponsored machines, we have not started dogfooding because of the reasons mentioned above. We have also published our scripting to launch the infrastructure to be entirety open, you can find the terraform and ansible scripting at https://github.com/go-gitea/infrastructure.

            1. 1

              Thanks for confirmation, good luck getting to the point where you are ready to self host!

      3. 1

        Fair comment. I can only think that Gitea doesn’t yet provide some of the core functionality they need (maybe pull requests or an issue tracker?). That said, a quick glance at their website didn’t actually tell me what functionality they do provide.

        Still, I do like the idea of a lighter weight self-hosted alternative to GitLab.

        1. 2

          Currently we provide only parts of the stuff we expect for hosting our code on our own. Contributions must be easy for everybody who wants to contribute, that’s why we said we need specific features to start with it.

          Edit: For the list of features (needs to be updated after the 1.1.0 release) just take a look at https://docs.gitea.io/en-US/#features

          1. 1

            Thanks for the reply - I didn’t mean to come across as critical and apologise if I did.


            I did see that list but it wasn’t detailed enough for me - it didn’t give me a comprehensive picture of Gitea’s functionality. I don’t want to have to install and configure something just to discover it’s missing a key feature I need.

            That said, I’m definitely going to give it a try - I’d been eyeing Gogs for quite a while before the fork.

            1. 2

              As a result of this we have extended the feature list now: https://github.com/go-gitea/docs/pull/99

            2. 1

              To discover more than just the key features it’s much easier to follow the button in the middle of https://gitea.io/en-US/, there you will get to https://try.gitea.io to play around with it, no need to install anything ;)

              Edit: https://try.gitea.io is always running on the latest version from the master branch.