techknowlogick

Hi, I'm on the TOC of Gitea, and I can definitively say that there is no cryptocurrency in Gitea or related to Gitea. As well, the project is not open-core, and you can verify that yourself by going to the project and seeing that all the code is MIT licensed: https://github.com/go-gitea/gitea

Hi, yes. That was me. I'm dealing with some health things and wasn't able to do much until recently, and I am working on continuing that conversation.

Just to add some heads up, CommitGo was on the roadmap, but establishing a company in the US takes time, so the initial org was created so that something could exist while the primary one was established. Hopefully more entities that are localized to specific geographic regions can be created as funding maintainers cross borders is a headache.

edit: we (the project and the company) are also receiving advice from several major open-source foundations on what establishing a foundation for the project would look like.

I commented here: https://news.ycombinator.com/item?id=41514547, but CommitGo was founded to ensure the longevity of the Gitea project. Due to the formation of the company more maintainers have been able to be paid for their time, and bounties/contracted work etc.. all go straight to the project.

I commented here: https://news.ycombinator.com/item?id=41514547, but it's different code, much more of an MVP than the fully fleshed-out functionality of this PR. Hopefully, it can be merged once the technical feedback has been addressed. We've seen with other areas of the project how DB degradation can impact the whole application, and have to deal with reports from users when they run into that. I'd rather the performance impact had at the very least a work around before it gets merged so when those issues are opened, then triaging them is much easier.

The in-progress PR was not pulled in, different code was written to log a small subset of events that this PR does. I commented here: https://news.ycombinator.com/item?id=41514547, but the PR is more fully fleshed-out and has more functionality, which hopefully can be merged.

I commented here: https://news.ycombinator.com/item?id=41514547, but tldr it's different code, much more of an MVP than the fully fleshed-out functionality of this PR. Once the PR is merged, effort to resolve conflicts would be minimal, as the other code logs only a fraction of the PR and doesn't overlap in most places. Hopefully the technical concerns can be addressed and the PR can be mereged.

Hi to be clear, there is a TOC of 6 members which there are elections yearly for the community spots, and it is the formal body that leads the project. The project has also more than doubled the number of community maintainers that can merge PRs, and over the past two years active PRs (merged, review, etc..) has gone from 100/mo to ~400/mo. But reviews from maintainers hold equal weight, and if they didn't then I would've been able to merge one of my PRs that took over 2 years to get in much faster.

I commented here: https://news.ycombinator.com/item?id=41514547, but tldr, its different code (a much more minimal implementation), and the PR isn't being prevented from merging, there is review that has feedback that hasn't been addressed yet. We have seen with other DB tables how when they grow significantly (and if you are logging every action this will happen) then performance is impacted. So there are suggestions on ways of addressing it in a way that wouldn't require manual intervention from users to resolve while waiting for additional PRs.

I commented here: https://news.ycombinator.com/item?id=41514547, but I wasn't able to continue my conversation with Kyle due to health reasons, but as I am recovering I am working on continuing them.

I commented here: https://news.ycombinator.com/item?id=41514547, but it's a different code, much more of an MVP than the fully fleshed-out functionality of this PR. Once the PR is merged, effort to resolve conflicts would be minimal, as the other code logs only a fraction of the PR and doesn't overlap in most places.

Hi. I'm techknowlogick, one of the two reviewers who have requested changes on this PR. A couple of clarifications: 1. I hadn't been able to continue my conversation with Kyle due to illness, and I am still dealing with it, but I am working on continuing that conversation. 2. The feedback that is holding up the PR is technical. Logging that amount of data has performance implications, and one of Gitea's main tenants is that it can run on reduced hardware. We know what impact it would have, as we are dealing with it from other tables. We don't have the ability to backport migrations to add indexes, etc.. (something that CommitGo has put a bounty on, though), so if it gets merged now and "well fix the filtering/etc.. later" means that if it gets merged then we have at least 6 months of bug reports around performance issues. 3. the code that is in the alternate distribution is different and doesn't include that PR. It is a few SQL inserts to log logins, package downloads, and git clones. 4. I am largely in favour of getting the PR merged, but if it means degraded performance and bug reports that we have to ask users to create DB indexes manually, that's something that I would hope could be avoided.

CommitGo, is the largest contributor to Gitea, and has contributed Actions in its entirety to the project. If the goal is to keep code away from the project for profit, that would be the one.

The priority of the company is to ensure the continued success of Gitea.

I love this kind of deep dive into customizing the software/OS on a device you own. Glad that "Tivoization" isn't a concern for the steamdeck.

The most interesting part of the article was the mention of a /nix partition, as I didn't realize the steamdeck supports nixpkgs, after researching it more, they do indeed (not installed by default, but at least it is possible without having to fork an entire os to get it on the device).

Hey, I'm the author of this post, and I just wanted to say thanks so much!

Hey. I'm the author of the post. Thanks for sharing the pricing link.

We've added everyone who signed up for the waitlist and will likely continue on this pace. We've just implemented it to scale the load on the service gradually, and once we have more real-world signup patterns, we'll be able to allow direct signups.

Right now, the CI/CD runners are linux based, and each tier has various limits on the number of minutes. It works out to about 200 minutes per user. Extending to be able to use other OSes is definitely on the roadmap.

If you sign up for the waitlist and then go into the dashboard you'll be able to see the exact limits of what you can sign up for (space, bandwidth, etc..), and also the discounts per tier.

The Blender Foundation has been wonderful! Among their many PRs to this release, one of the big ones was scoped labels.

No worries, that's totally understandable. The change was made mostly for practical reasons, to be able to upgrade infrastructure piece by piece. So both new and old infra could run at the same time while it was switched. I'm actually writing a blog post detailing the history of our infra, but the TLDR is that too much money and person effort was being spent on managing the infra.

Disclaimer: I am a part of the Gitea TOC, and am employed to work on Gitea.

That's an awesome use-case! Are you using LFS in Gitea too with Unity?

Are you working on anything publicly available? I'm looking for something new to play :)

Disclaimer: I am a part of the Gitea TOC, and am employed to work on Gitea.

I was just telling someone else how great Woodpecker is.

The protocol that Actions runners use to report logs/job statuses back to Gitea is an open protocol that maybe one day woodpecker could use it for enhanced integration with Gitea, so you could use woodpecker but have the experience be next to your code.

Disclaimer: I am listed as a maintainer of Woodpecker. I am a also part of the Gitea TOC, and am employed to work on Gitea

One contributor to nektos/act and Gitea's act_runner (ChristopherHX) contributor "host" mode to act, which allows you to run without docker.

Disclaimer: I am a part of the Gitea project, the TOC, and am employed to work on Gitea

What was your experience like with GSOC? Gitea has applied to it this year, and are hoping to be able to make it a good experience for any contributor that is matched (hopefully we are accepted as well).

Yup, it was one of the candidates. https://devtalk.blender.org/t/developer-blender-org-call-for...

I.... uhh... can't say I tried that... as it's against the TOS... cough All joking aside, they have banned accounts from other projects attempting to do the same, so if I were to do that (and I'm not saying that I would), I'd want to make sure that the exporter is solid prior to risking any account.

Thanks, yeah. We have started to look at that alternative endpoint, but it doesn't have the exact data as the api, nor is it always in the exact same format.

Although as I have run the migration myself several times to attempt to debug issues, it takes over 24hours due to ratelimiting.

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

That's correct. It is not due to load, gitea.com already has most of the projects repos migrated already, just not the main one due to ratelimits and exporting all the issues. Gitea.com has thousands of users, and multi-TB traffic monthly on a fairly modest setup.

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

Yup, that's right. Non-repo data (releases, avatars, packages, etc..) can all be hosted in s3-compat storage.

If you are interested in some benchmarks that Blender did you can find them here: https://code.blender.org/2023/02/gitea-test-drive/

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

Yes, this is exactly the case. Lots of data, and low ratelimits don't mix. All except for the main repo have already migrated to gitea.com

Disclaimer: I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea.

Hi, I'm one of the members of the technical oversight committee of the Gitea project, and am employed to work on Gitea. The reason why the project itself is still on GitHub is due to the massive amount of metadata (20K+ issues and PRs, and all the comments, reactions, and other metadata attached to them) around the project, and the ratelimiting that is slowing the export. All the non-primary repos have long since moved to gitea.com.

Hi, I'm the author of the blog post. Thank you for your comment. A project you may find interesting is soft-serve from charm.sh https://github.com/charmbracelet/soft-serve it's a "TUI" (terminal user interface).

Hi Barnabee. I'm the author of the blog post. Thanks for your comments. I'd be interested to know why you would prefer funding come from an external crypto token instead of a paying for a hosted version. I would think that dogfooding is a way to stay on focus on the main project instead of being distracted by something else.