The "CTR vs RTC" discussion is an important one for a community to
have. In my opinion, there's no easy answer. (I'm basically agreeing
with Bertrand here.) It is certainly useful to have a default process,
and that default process should probably be RTC. But also develop
trust so that people who have gained merit can move faster. ("Just do
it" and "Small reversible steps" are ASF mantras that support that
philosophy.)On Tue, Nov 15, 2022 at 4:42 AM Bertil Chapuis <bchap...@gmail.com> wrote: > > Thank you Andrea and Bertrand for your answers. > > I agree with you Andrea, it is a good practice to have several people > reviewing PRs. The problem right now is that a lot of small changes are > required to make progress on the first release. Some of these changes need to > be in main in order to be tested (e.g. github page configuration). I don’t > want to bother everyone with these changes and I also want to revert failed > experiments (I know this is bad, but the history will be cleaner ;). > > I suggest we remove the branch protection rule for now and act responsibly > when it comes to asking for reviews. > > > > On 15 Nov 2022, at 10:20, Bertrand Delacretaz <bdelacre...@apache.org> > > wrote: > > > > Hi, > > > > Bertil Chapuis <bchap...@gmail.com> wrote: > >> ...Do you think we should relax the current policy and disable the review > >> requirement?... > > > > I think it's good for the project to define whether it wants to > > operate in CTR or RTC mode (Commit-Then-Review or Review-Then-Commit, > > [1]) > > > > IMO declaring CTR generally (which means no pre-merge review required) > > and if needed RTC for some critical parts of the code works well. > > > > People are supposed to watch the commit logs and especially review > > changes before making releases, so in general I think CTR is fine. > > > > -Bertrand > > > > [1] https://www.apache.org/foundation/glossary.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org > > For additional commands, e-mail: dev-h...@baremaps.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org For additional commands, e-mail: dev-h...@baremaps.apache.org
