Difference between revisions of "Organisation"
(→System) |
|||
Line 1: | Line 1: | ||
== System == | == System == | ||
− | Minetest's organization update of 2014-01-02: | + | With the goal of lessening the likeliness of pull requests being left hanging around, making it clearer who knows what, giving more motivation via responsibility and change for the sake of change, Minetest's organization update of 2014-01-02: |
The engine is split into virtual "subsystems" based on the most easily definable but still meaningful parts of the code (mostly each file should belong to one subsystem, but this is not strictly possible). | The engine is split into virtual "subsystems" based on the most easily definable but still meaningful parts of the code (mostly each file should belong to one subsystem, but this is not strictly possible). |
Revision as of 11:39, 2 January 2014
System
With the goal of lessening the likeliness of pull requests being left hanging around, making it clearer who knows what, giving more motivation via responsibility and change for the sake of change, Minetest's organization update of 2014-01-02:
The engine is split into virtual "subsystems" based on the most easily definable but still meaningful parts of the code (mostly each file should belong to one subsystem, but this is not strictly possible).
Each subsystem is allocated to one "subsystem maintainer", who is responsible for making sure pull requests get handled and fixing the subsystem if it doesn't work. Subsystem maintainers are trusted to give their permissions and/or responsibiltiies to someone else too if they see fit.
Subsystems
Developer | Subsystem |
celeron55 | maintainer conflicts |
sapier | server/client/env |
kahrl | startup/config/util |
ShadowNinja | script API |
hmmmm | mapgen |
celeron55 | client/audiovisuals |
sapier | low-level network |
thexyz | build system |
proller | masterserver |
ShadowNinja | Documentation |
Those positions will maybe be assigned in the future:
releases
voting/community
Subsystem Files
(TODO)