3 ms·

If it’s good enough to merge into the enterprise branch, it’s good enough to merge into the community branch. It may be expensive; that’s why there was a commu

If it’s good enough to merge into the enterprise branch, it’s good enough to merge into the community branch. It may be expensive; that’s why there was a community-funded bounty placed on it. If the complaint is that Gitea is too complex to maintain for free, then great, start a company around it to fund a private fork. But then you shouldn’t be allowed to stop the community from merging their own crap in their own fork that they maintain and care about. Since Gitea LTD is the gatekeeper of both repos, that is the conflict of interest.

evanelias 2y ago
> If it’s good enough to merge into the enterprise branch, it’s good enough to merge into the community branch. It's not clear yet that the Enterprise version of this feature is the same code as this PR, right? Do you have evidence otherwise? > It may be expensive; that’s why there was a community-funded bounty placed on it. How much was the bounty, who funded it, and who receives it? I don't see any information about that on the PR or the linked issue. > you shouldn’t be allowed to stop the community from merging their own crap in their own fork that they maintain If the community really maintains it 100%, then they would all be maintainers and by definition they would be able to merge it already. That doesn't appear to be the situation here. > Since Gitea LTD is the gatekeeper of both repos, that is the conflict of interest. Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project? And since the complaining commenter is CTO of a company who benefits from being able to include this feature in his company's own private fork, doesn't he have a conflict of interest as well?
- ironmagma 2y ago
  > Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project? Absolutely not, and I never made that claim. > How much was the bounty, who funded it, and who receives it? I happen to have some inside knowledge here, that at least Allspice and Copia provided parts of the bounty. Some of that is mentioned in the thread but the transparency could be better. > Do you have evidence otherwise? That was the thrust of the submission. I tried to link the fragment but I don't think Hacker News allows that and erased it: "Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So Gitea Ltd. (owners group) has no incentive to review and merge this in an open source repo, even though the open source community has funded and developed it." As for conflicts of interest, perhaps. Who knows the actual extent of it? Posting here is intended a matter of visibility rather than activism; that's why I'm so surprised that the thread was closed on grounds of brigading, since that was neither the intended nor the actual effect.
  - evanelias 2y ago
    > I happen to have some inside knowledge here, that at least Allspice and Copia provided parts of the bounty. Some of that is mentioned in the thread but the transparency could be better. Can you please link to whatever part of this bounty is public? I just expanded searched the PR comments for "bounty" and absolutely nothing came up, and likewise on the issue linked from the PR. In any case, if the bounty is coming from companies other than Gitea Ltd, and it presumably will be paid to the PR submitter (and not to Gitea Ltd), then how does this bounty help compensate for the massive amount of time Gitea Ltd employees spend on code review and long-term maintenance of this huge PR? > That was the thrust of the submission. I tried to link the fragment That quote is an unsubstantiated claim from the commenter making the complaint. It might be accurate or it might not. As a neutral third party I have no way of evaluating that, as no evidence has been presented. Personally, I haven't flagged this thread, but I can absolutely understand why others did so, given the complete lack of any concrete evidence of the main thing being claimed here.
- lostmsu 2y ago
  > Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project? One does not preclude the other. > And since the complaining commenter is CTO of a company who benefits from being able to include this feature in his company's own private fork, doesn't he have a conflict of interest as well? He isn't controlling what goes into community repo, so that's irrelevant.
- techknowlogick 2y ago
  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.
techknowlogick 2y ago
I commented here: https://news.ycombinator.com/item?id=41514547 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.

evanelias 2y ago

> If it’s good enough to merge into the enterprise branch, it’s good enough to merge into the community branch. It's not clear yet that the Enterprise version of this feature is the same code as this PR, right? Do you have evidence otherwise? > It may be expensive; that’s why there was a community-funded bounty placed on it. How much was the bounty, who funded it, and who receives it? I don't see any information about that on the PR or the linked issue. > you shouldn’t be allowed to stop the community from merging their own crap in their own fork that they maintain If the community really maintains it 100%, then they would all be maintainers and by definition they would be able to merge it already. That doesn't appear to be the situation here. > Since Gitea LTD is the gatekeeper of both repos, that is the conflict of interest. Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project? And since the complaining commenter is CTO of a company who benefits from being able to include this feature in his company's own private fork, doesn't he have a conflict of interest as well?

ironmagma 2y ago
> Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project? Absolutely not, and I never made that claim. > How much was the bounty, who funded it, and who receives it? I happen to have some inside knowledge here, that at least Allspice and Copia provided parts of the bounty. Some of that is mentioned in the thread but the transparency could be better. > Do you have evidence otherwise? That was the thrust of the submission. I tried to link the fragment but I don't think Hacker News allows that and erased it: "Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So Gitea Ltd. (owners group) has no incentive to review and merge this in an open source repo, even though the open source community has funded and developed it." As for conflicts of interest, perhaps. Who knows the actual extent of it? Posting here is intended a matter of visibility rather than activism; that's why I'm so surprised that the thread was closed on grounds of brigading, since that was neither the intended nor the actual effect.
- evanelias 2y ago
  > I happen to have some inside knowledge here, that at least Allspice and Copia provided parts of the bounty. Some of that is mentioned in the thread but the transparency could be better. Can you please link to whatever part of this bounty is public? I just expanded searched the PR comments for "bounty" and absolutely nothing came up, and likewise on the issue linked from the PR. In any case, if the bounty is coming from companies other than Gitea Ltd, and it presumably will be paid to the PR submitter (and not to Gitea Ltd), then how does this bounty help compensate for the massive amount of time Gitea Ltd employees spend on code review and long-term maintenance of this huge PR? > That was the thrust of the submission. I tried to link the fragment That quote is an unsubstantiated claim from the commenter making the complaint. It might be accurate or it might not. As a neutral third party I have no way of evaluating that, as no evidence has been presented. Personally, I haven't flagged this thread, but I can absolutely understand why others did so, given the complete lack of any concrete evidence of the main thing being claimed here.
lostmsu 2y ago
> Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project? One does not preclude the other. > And since the complaining commenter is CTO of a company who benefits from being able to include this feature in his company's own private fork, doesn't he have a conflict of interest as well? He isn't controlling what goes into community repo, so that's irrelevant.
techknowlogick 2y ago
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.

techknowlogick 2y ago

I commented here: https://news.ycombinator.com/item?id=41514547 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.