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.

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

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

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?

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.

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

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

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

Since the control will be minimal, the second variant

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

What are the benefits?

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.

Have some faith.

I don’t have any experience with PR or really open-source development at all. But I’m familiar with how it works. This sounds interesting and I think the information gained from either success or a mess would be valuable to regular Urho3d. I won’t be doing any developing, but I’ll be happy to play around with the end result of the experimentation.

There is only one thing I would propose/hope. Hopefully when we cherry-picking the good bits from this new community fork, we don’t have to treat them as third-party, that is when the code are contributed by its original author they already agreed to the same contribution checklist of Urho3D project and to be using MIT license with the same copyright statement.

Nevermind, I’ll just leave you guys to your dark ritual.
…and adopt Urho as a patron saint.

Anyone has the right to fork in open source project.

The fork will have the same license with “Urho3D project” copiright so no consent is required, but of course it’s better to add a mention of the transfer

I’m not stopping anyone: Go ahead… fulfill the prophecy. << α ω

_{Bloody coincidentists.}

Is it possible to fork repo to same organization?

glebedev and Eugene helped me make the rules. Any notes?

1. It is guaranteed that your PR will be accepted in a week if nobody objects to it or suggests an improvement. No comments means everybody agrees with the PR.
2. Please test your change thoroughly. PR will be accepted quickly probably with only light eyeballing so the PR author is solely responsible for the quality of the change.
3. Most useful changes will be merged to Urho3D master branch. To make this simple, consider squashing the PR into a single commit so it would be easy to cherry-pick it.
4. Please try keep Urho3D code style in your change. You can keep any style in your change but any deviation from Urho3D code style requires additional effort to merge it into master. Engine maintainers may avoid it.
5. You are welcome to make PR to fix a bug or add new feature
   5.1. Don’t reduce engine functionality. The only exception would if the feature is outdated, not in use by anyone and blocking your PR.
   5.2. Don’t change existing code style. You can clean up, reformat or refactor code you wrote previously. Changing someone else’s code may trigger a downward spiral of hatred. Just leave it as is.
   5.3. Don’t spend your time on tweaking interface colors, new logo design, etc. It is highly subjective and a matter of opinion. If you want to make a beautiful art work with Urho3D consider making it in a separate repository and paste link to in at https://discourse.urho3d.io/c/showcase/17
6. It would be great if new code will be accessible via scripting languages. You can provide script bindings but you don’t have to.

I don’t think it’s possible to fork to the same GitHub account, I think you have to just make a new repo and then push from a local copy. Though it seems you can also import it from GitHub. Either way, it looks like it’s not possible to create a PR from the new repository to the old one.

I like the rules. I think I might mention the binding generators in point 6 to emphasize that this is a lot less work now than it used to be. Though I think it’s also not necessary to do so.

Also, it may just be the forum’s flavor of markdown, but I think if you add a few more spaces before the sub items bullet points in point 5 they may end up indented and appear as more definitive sub items rather than seeming to be at the same level.

Spaces don’t work, I changed dots to numbers

I have been thinking, why not you just do the work on the master branch directly then. You can make a copy of current master branch to another branch and named it “stable” or “main” or what have you. In the past we have kept our master branch as stable as possible, but I don’t think it has to be this way. It is a trade-off. However, since I will be taking a long break from this project, I don’t have to worry about it.

In the past we have kept our master branch as stable as possible, but I don’t think it has to be this way

Maybe that’s not a bad idea since newcomers probably won’t know about this approach and will keep submitting PR’s to master.

Anyway I think that this is a great idea overall. Master branch should be updated as often as possible even if it means that there are mistakes and/or bugs, releases should be used for marking stable builds.

I don’t understand the goal anymore. Can you elaborate, please?

If you want to merge low-quality untested not-codestyle-conforming PRs (like @1vanK proposed), it cannot be master branch. I don’t think I need to argue why master branch is not a trash can. Especially given that we currently have “releases are outdated, use master branch, it’s stable” poilcy.

If you want to carefully review and quality-check PRs, I don’t see how it’s different from current PR policy.

You’re right, I think I ignored a few of the rules that @1vanK proposed. Ignore my previous post as it is not related to the proposal.

Looks, it is all the same, whichever repo or branch you want to designate it as stable and which one is unstable. If 1vanK wants it to be in the prime area under “urho3d” org then we need to two of them. One mark as stable and one as unstable. The new relax rules obviously only apply to the unstable branch/repo. I propose to use the existing master branch as the one designated for unstable because that is the branch normally developer assume to be the target of the PR.

It is just an idea. If he wants it to be a experimental fork outside then I will not suggest this in the first place. But if he want to make in the “urho3d” org, why not just switch places. You still have the stable branch as we have now, but just name it differently. Think outside the box. Or if you guys cannot wrap your ahead around still, leave the current master branch as it. Just name the new repo/branch as “unstable”. Cheers.

I think you still miss my point, but that’s OK. Just want to make a simple comparison. In Emscripten, they have a branch named “incoming” and another one named “master”. Over there, people understood to send PR to the “incoming” branch. We do not have that kind of setup for Urho3D project. But if we do, I would rather have “master” branch as the branch for accepting PR, because I find myself sending PR to non-default branch to be confusing. Of course, if we do this, the formerly known “master” branch will be renamed and maintained separately. So, you don’t lose anything in term of stability.

Again, this is non-issue if the experiment is to be carried out outside of the “urho3d” org.

Too risky experiment, I think. I just created a second organization for this.

No pain no gain But, it is your call and I respect that.

I added a link to the repository in the first post.

Shouldn’t we add some reference, in the website or the README as well?

As it is in a different org, it will be hard to find for other people which are unaware of this thread.

There is no problem to send people there who send pull requests that are not suitable for the main repository.