RFC: Changes in organization

celeron55
Administrator
 
Posts: 452
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

RFC: Changes in organization

by celeron55 » Sat Feb 07, 2015 16:33

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
Location: Australia
GitHub: Zeno-

Re: RFC: Changes in organization

by Zeno » Sat Feb 07, 2015 16:55

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: 130
Joined: Sat Feb 07, 2015 17:16
Location: France
GitHub: nerzhul
IRC: nrzkt
In-game: nrz

Re: RFC: Changes in organization

by nrz » Sat Feb 07, 2015 17:45

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: 4299
Joined: Thu Oct 03, 2013 07:48
Location: Switzerland
GitHub: SmallJoker

Re: RFC: Changes in organization

by Krock » Sat Feb 07, 2015 18:33

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

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

Re: RFC: Changes in organization

by sfan5 » Sat Feb 07, 2015 19:08

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: 4429
Joined: Sun Apr 01, 2012 12:38
Location: Waynesville, NC
GitHub: VanessaE
IRC: VanessaE
In-game: VanessaE

Re: RFC: Changes in organization

by VanessaE » Sat Feb 07, 2015 19:10

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
 

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

Re: RFC: Changes in organization

by Wuzzy » Sun Feb 08, 2015 02:08

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: 130
Joined: Sat Feb 07, 2015 17:16
Location: France
GitHub: nerzhul
IRC: nrzkt
In-game: nrz

Re: RFC: Changes in organization

by nrz » Sun Feb 08, 2015 08:36

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

celeron55
Administrator
 
Posts: 452
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: RFC: Changes in organization

by celeron55 » Mon Feb 09, 2015 14:53

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.
 

celeron55
Administrator
 
Posts: 452
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: RFC: Changes in organization

by celeron55 » Mon Feb 09, 2015 15:11

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: 130
Joined: Sat Feb 07, 2015 17:16
Location: France
GitHub: nerzhul
IRC: nrzkt
In-game: nrz

Re: RFC: Changes in organization

by nrz » Mon Feb 09, 2015 15:24

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

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

Re: RFC: Changes in organization

by rubenwardy » Mon Feb 09, 2015 16:47

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: 3435
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: RFC: Changes in organization

by Wuzzy » Mon Feb 09, 2015 19:11

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: 5756
Joined: Tue Jun 12, 2012 18:11
Location: United Kingdom
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
 

celeron55
Administrator
 
Posts: 452
Joined: Tue Apr 19, 2011 10:10
GitHub: celeron55
IRC: celeron55

Re: RFC: Changes in organization

by celeron55 » Tue Feb 10, 2015 14:42

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
 


Return to General Discussion



Who is online

Users browsing this forum: No registered users and 1 guest