RFC: Changes in organization

Post Reply
User avatar
celeron55
Administrator
Posts: 464
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

RFC: Changes in organization

by celeron55 » Post

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

Zeno
Member
Posts: 140
Joined: Sun Jun 29, 2014 03:36
GitHub: Zeno-
Location: Australia

Re: RFC: Changes in organization

by Zeno » Post

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).

nrz
Developer
Posts: 131
Joined: Sat Feb 07, 2015 17:16
GitHub: nerzhul
IRC: nrzkt
In-game: nrz
Location: France
Contact:

Re: RFC: Changes in organization

by nrz » Post

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.

User avatar
Krock
Developer
Posts: 4556
Joined: Thu Oct 03, 2013 07:48
GitHub: SmallJoker
Location: Switzerland
Contact:

Re: RFC: Changes in organization

by Krock » Post

Finally some changes in the "rules" of this game!
I like the idea of a stable branch, let's see how good it works.
Look, I programmed a bug for you. >> Mod Search Engine << - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>

User avatar
sfan5
Moderator
Posts: 3929
Joined: Wed Aug 24, 2011 09:44
GitHub: sfan5
IRC: sfan5
Location: Germany

Re: RFC: Changes in organization

by sfan5 » Post

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.
Mods: Mesecons | WorldEdit | Nuke & Minetest builds for Windows (32-bit & 64-bit)

User avatar
VanessaE
Moderator
Posts: 4536
Joined: Sun Apr 01, 2012 12:38
GitHub: VanessaE
IRC: VanessaE
In-game: VanessaE
Location: Western NC
Contact:

Re: RFC: Changes in organization

by VanessaE » Post

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
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)

TriBlade9
Member
Posts: 89
Joined: Fri Sep 05, 2014 09:35

Re: RFC: Changes in organization

by TriBlade9 » Post

Minor itch: s/originator/author.

User avatar
Wuzzy
Member
Posts: 4046
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: RFC: Changes in organization

by Wuzzy » Post

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? ;-)

nrz
Developer
Posts: 131
Joined: Sat Feb 07, 2015 17:16
GitHub: nerzhul
IRC: nrzkt
In-game: nrz
Location: France
Contact:

Re: RFC: Changes in organization

by nrz » Post

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

User avatar
celeron55
Administrator
Posts: 464
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: RFC: Changes in organization

by celeron55 » Post

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.

User avatar
celeron55
Administrator
Posts: 464
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: RFC: Changes in organization

by celeron55 » Post

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."

nrz
Developer
Posts: 131
Joined: Sat Feb 07, 2015 17:16
GitHub: nerzhul
IRC: nrzkt
In-game: nrz
Location: France
Contact:

Re: RFC: Changes in organization

by nrz » Post

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

User avatar
rubenwardy
Moderator
Posts: 6251
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: RFC: Changes in organization

by rubenwardy » Post

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.

User avatar
Wuzzy
Member
Posts: 4046
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: RFC: Changes in organization

by Wuzzy » Post

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?

User avatar
rubenwardy
Moderator
Posts: 6251
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: RFC: Changes in organization

by rubenwardy » Post

SemVer won't be introduced until after 0.4.12.

User avatar
celeron55
Administrator
Posts: 464
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: RFC: Changes in organization

by celeron55 » Post

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

Post Reply

Who is online

Users browsing this forum: bebebeko and 3 guests