At the moment, our engine has a problem that PRs are accepted for a very long time or not at all. The people who made PRs rightly take offense and leave. As an experiment, I propose to create an official fork in which we will accept PRs with little or no checking. And the most successful ones will be transferred to the main stable version. I suspect that this fork will soon turn into a nightmare. In the end, we will at least have a good example of what will happen to the engine if we accept all incoming PRs.
So idea is a broken version that noone will use because all junk is accepted? I do not see what this will achieve other than waste time of maintainers.
High quality control for PRs is a good thing. Lack of any response is actual problem. Also you should not hesitate to close PRs that have long stalled and have either nothing that useful or no chance to be revived, or both.
You complained to me that nobody understood your ideas, so you forked the Engine. Or do you think that only your PRs should be accepted and everyone else is garbage?
How is having low quality “community edition” related to forks?
Forking is the tool to implement breaking, risky and/or very specialized changes that cannot be merged to master due to this. It’s the primary use case of Urho - to be forked and adjusted instead of being used as is.
I don’t see how it’s related to this particular topic.
Does “official fork” include responsibility of maintainers (I guess it’s you, because it’s your suggestion) to keep this fork up to date with main repo?
Are contributors responsible for PR transferring? I.e. if main repo receives trash PR or vice versa.
This is just an experiment. It is unknown how long it will last. And how much activity from contributors will be. At first, until there are big discrepancies, it will be easy to update the fork from the master.
PRs will be merged if no one has made a notes for several days. Silence = agreement.
As for responsibility, I don’t understand what you are talking about. Everything happens on a voluntary. For example, are you responsible for something or not?
I support this idea.
Moreover, we already have such code in main repo (changes of CustomGeometry in this PR).
I mean, these helpers clearly don’t belong to this class. These functions don’t need access to private members of CustomGeometry, don’t belong to initial API domain of CustomGeometry and are not reusable enough to be common helpers.
I think this is exactly the kind of code “communtiy fork” should harbour.
Well, I don’t know about GitHub… I’m not getting near that corporate botnet.
But on GitLab branches can be marked protected. This prevents “force pushing” and only allows maintainers (not developers) to push to these branches. By default the master branch is marked as such.
What’s important is that the master branch compiles just fine.
There’s also plenty of examples of people creating feature-specific forks, which is fine. A general “experimental fork” is simply too wide a scope to merge from, keep synced and tidy. It doesn’t solve the problem, it only sounds nice while splitting the fish in two.
This is not software development, it is fantasy marketing.
Developers should not be treated as outsiders, and responsibility should not be confused with status. When a community-driven project is asking for a “community edition”, it may be lacking confidence.
