Minetest Forums

Based on a discussion with nrzkt/nerzhul it looks like I need to refresh things a bit to make sure development will continue strongly in the future. I request comments to these changes:

Policy changes/additions:

• The master branch will not be used anymore for feature freezes. A new feature freeze branch will be created when a release is to be made, to which bugfixes are applied until it's considered stable. (It can be extended to be a more complete release model later, but this is the important part for now.)
• If a pull request or an issue does not get a response from its originator in one month, it is closed.
• If an issue is a duplicate, refer to the first one and close the later ones.
• People who are not active and constructive will not keep their core developer status. (There is no way to make this not vague; celeron55 will accept complaints and will ultimately decide.)
• If a core developer does not have time for doing anything, his tasks will be moved to be done by someone else. (Again, celeron55 will accept complaints and will ultimately decide.)

Other things:

• The current feature freeze will be transformed to a branch immediately, because hmmm has been sitting on a bugfix for way too long and is causing an unnecessary stall in development.

EDIT: Also, I'll have to make our existing rules more easy to find because I can barely find them myself. Not that we have many to begin with, though.
EDIT: These changes take effect after a day or two, depending on the comments.
EDIT 2015-02-09: I updated the development wiki to contain these rules and organized them in a more accessible way: http://dev.minetest.net/All_rules_regar ... evelopment

The new branch is something I've wanted for a while (and I obviously agree with).

Currently the hold up is an apparent regression in (simple)singleplayer games. It's very hard to profile to see what's going on (and, yeah, I've tried and so has hmmm).

For PR cleanup, you can look at here: https://github.com/minetest/minetest/pu ... +is%3Aopen

Maybe some old issues can be kept because they are pertinent but many old PR are unmergeable or useless.

Thanks for the post celeron55.

Finally some changes in the "rules" of this game!
I like the idea of a stable branch, let's see how good it works.

I agree with Zeno, a seperate feature-freeze branch is a good idea.
Especially since we've been in a feature-freeze for 2 (or 3?) weeks without any significant development (not fixes) taking place.

Seems fair to me - much larger projects than us use a similar development model to good effect.

Related, hmmmm's "Release Engineering" and "Quality Assurance" posts:

viewtopic.php?f=3&t=10848
viewtopic.php?f=3&t=10849

Minor itch: s/originator/author.

If a pull request or an issue does not get a response from its originator in one month, it is closed.

Will it also be closed if it does not get a response from its originator because everybody else ignored/overlooked/did not care to comment for it? ;-)

Wuzzy, originator = author. Issue needs response from minetest developers, it's a ticket which needs to be answered if possible

I updated the development wiki to contain these rules and organized them in a more accessible way: http://dev.minetest.net/All_rules_regar ... evelopment

It's not likely that these cause any other immediate things to happen other than the freeze-0.4.12 branch to be created and a few pull requests and issues to be cleaned up.

I created the branch now so that pull requests don't have to be postponed further.

I also added a new rule here that I did not mention in this topic yet:
http://dev.minetest.net/Git_Guidelines# ... and_issues

"People considering merging pull requests are not required to look anything up anywhere else than the pull request and its comments. If there is something blocking the merging of a pull request, the reason must be added as a comment to the pull request."

Good idea, PR mustn't been blocked because of other PR.

That makes sense. Instead of saying req 1-5, I suggest you make it more meaningful such as req roadmap, works, codestyle, protocol, etc. But doesn't matter - easy to look up.

Hopefully this will stop stagnation of development.

Slightly offtopic, my main concern about the project so far is the quality of user interface in terms of ease of use, aesthetics and gamplay. Hopefully the subsystem leaders will improve this. It should be maybe clarified that the client/audiovisuals includes making sure the user interface is good. Or maybe a meta subsystem.

The change in feature freeze is good. I have avoided doing pull requests as they won't be merged until it's over, so no rush.

freeze-x.x.x

freeze-0.4.12

So is SemVer not considered, as discussed here?: viewtopic.php?f=3&t=10848

Or is “freeze-x.x.x” just the name of the branch?

SemVer won't be introduced until after 0.4.12.

I have changed the two core developer related rules to these:

• If a core developer is doing almost nothing but blocking everything that comes their way, they will be unassigned. (celeron55 will accept complaints and will ultimately decide.)
• Core developers, like other contributors, should document and publish their work in a way that allows another contributor to pick up on it if the core developer stops working on the project due to any reason.

These are kind of the same thing as before, but without the activity requirement. It was a bit weird considering the composition of the core team.

http://dev.minetest.net/Organisation#Core_developers