Urho3D Community edition

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.

  • Yes
  • No

0 voters

EDIT: https://github.com/Urho3D-CE/Urho3D

5 Likes

That’s actually a good idea. Like Debian Sid or something. “Urho3D-Experimental”.

1 Like

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.

2 Likes

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?

Where did i say that? Look at PRs from me. I submitted some garbage as well. So?

Your PR is great, the best of all

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.

I added a vote to the first post

I have two questions about the subject.

  1. 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?

  2. 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?

At the very least, we can impose a limitation on reducing functionality, if you contribute, the rest of the things should not stop working.

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.

1 Like

Don’t create a fork, when you should be branching.

Experiments should be specific. Otherwise you’re just starting another alchemists’ guild. :boom:

Doesn’t GitHub have protected branches and permissions, like GitLab?

Would the Community Edition work like Debian’s Sid? Like whatever is in there will eventually be pushed to main Urho3D?

Or main Urho3D will cherry pick changes from the Community Edition?

Since the control will be minimal, the second variant

So if the Community Edition eventually becomes so divergent, that it’s no longer viable to backport changes, main Urho3D will continue to exist as it is, right?

If some PR is good, we will ask the authors to make it for the main repository.

Looks good. Thank you.

:scroll::musical_score:

Fish Executioner

Fish Executioner!
Death to be done on this blasphemous day
Fish Executioner!
Face of the dead fish will never go away


What are the benefits?