Proposal to get faster releases in minetest

faster_release_proposal.txt

Goal: Reduce release delay and uncertainty.

Reasons I saw why releases get delayed:

* the milestone doesn't get empty
  * there's some regression(s). and a bugfix is not in sight
  * someone wants a 90% complete feature in the next release
* coredevs inactive. (no active work being done to get progress in the remaining
  issues)
* nobody feels responsible to do reverts. and nobody wants to, because doing so
  would make you the meanie that undoes the contributor's work

Proposal: Get more rigorous / bureaucratic with the milestone.

In details:
(numbered solely for the purpose of referencing a specific point)

(1) At start t_start of the dev cycle (after last release), schedule a fixed
    date t_rls for the next release.
    (And fill the milestone with big features / changes that are meant to be
    included in the next release.)
(2) If at date t_bug_i there's a regression bug_i (regression relative to last
    release) found, add it to the milestone.
(3) In each meeting, discuss the progress of each item in the milestone.
(4) If the meeting happens at least 30 days after t_bug_i, if bug_i is not fixed,
    revert the commit that introduced bug_i.
    (Or merge a PR that fixes bug_i during the meeting. Either way, bug_i must
    be out of the milestone at the end of the meeting.)
    Exception: Can instead also mark bug_i as being mild enough to be shipped in
    the release.
(5) At about half of the dev cycle (e.g. in the first meeting after
    `t_start + (t_rls - t_start) / 2 - 30 days`), make sure each feature in the
    milestone has a contributor assigned to it.
(6) If the meeting happens no more than 30 days before t_rls, remove all features
    from the milestone that are not realistically going into the next release.
    (They can still be merged, but it makes no sense having them in the milestone
    if we don't want to guarantee them being merged.)
(7) Two weeks before t_rls, brutally rip out all remaining features in the
    milestone, and enter feature freeze.
(8) During feature freeze, if the milestone is not empty, hold weekly meetings (as
    opposed to 2-weekly).