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.
Heads up would have been explaining this at the time and not silently transferring ownership of the domain to a second for-profit entity with no lead up and no announcement [0]. I'd have thought that after the trademark fiasco you'd have learned to be more open about your intentions for your for-profit arms, but it seems you might have taken the opposite lesson.
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.
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.