The convention of submitting a pr and then waiting for an independent approval before merging is perhaps not well-tuned to our current development situation.
We don't have lots of programmers making changes in the core Medley code, and we don't have a phalanx of people to do the safeguarding that comes from independent approvals. (Also, our current "product" is not being used to control nuclear power plants.)
The consequence is that pr's can languish for quite awhile (for weeks if not months), before the very few of us have time or inclination to inspect and approve. And a side-effect of that is that we end up with a tree of pr's, with inherited dependencies, as development continues along one or more paths. Which makes the approval even more complicated.
So I propose changing our approval/merging policy so that changes don't get hung up for indefinite periods of time. When a pr is submitted, that starts a clock running to give time for independent inspection, comments, and even old-style approvals. The clock runs for, say, 7 days, and if no serious problems have been brought up during that period, then the pr is available for merging, even by its original author.
If nobody looks at it during the week, it may be that a serious problem (or an even better implementation) will be missed. But if issue emerges later, with git we can always back up and redo.
In sum, in our situation and with our people and resources, I think we should reduce the overhead and delay that comes from asking for permission in advance of doing a merge, and instead ask for forgiveness after the fact, if we screw things up. With a week in the middle to minimize the risk.
The convention of submitting a pr and then waiting for an independent approval before merging is perhaps not well-tuned to our current development situation.
We don't have lots of programmers making changes in the core Medley code, and we don't have a phalanx of people to do the safeguarding that comes from independent approvals. (Also, our current "product" is not being used to control nuclear power plants.)
The consequence is that pr's can languish for quite awhile (for weeks if not months), before the very few of us have time or inclination to inspect and approve. And a side-effect of that is that we end up with a tree of pr's, with inherited dependencies, as development continues along one or more paths. Which makes the approval even more complicated.
So I propose changing our approval/merging policy so that changes don't get hung up for indefinite periods of time. When a pr is submitted, that starts a clock running to give time for independent inspection, comments, and even old-style approvals. The clock runs for, say, 7 days, and if no serious problems have been brought up during that period, then the pr is available for merging, even by its original author.
If nobody looks at it during the week, it may be that a serious problem (or an even better implementation) will be missed. But if issue emerges later, with git we can always back up and redo.
In sum, in our situation and with our people and resources, I think we should reduce the overhead and delay that comes from asking for permission in advance of doing a merge, and instead ask for forgiveness after the fact, if we screw things up. With a week in the middle to minimize the risk.