Urho3D Community edition

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. :tropical_fish: :axe:
…and adopt Urho as a patron saint.

Anyone has the right to fork in open source project.

3 Likes

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. :wastebasket: << α ω

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

1 Like

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. :slight_smile:

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.

1 Like

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.

1 Like

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

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