I’m not suggesting RTC. No Review required. It’ll be CTR, just making the review post commit easier to do.
> On Jun 19, 2020, at 12:23 AM, Christofer Dutz <[email protected]> > wrote: > > Hi folks, > > I do understand the reasoning. But as an example the apache training decided > to switch to review then commit and that totally drained the community. What > started with quite some people with a lot of enthusiasm, is currently > struggling to not appear a dead community. > > If you are having trouble with people breaking things and want to solve this > problem that way, so you have the additional bandwidth to do the reviews? > > Perhaps investing in automated tests could be a better invest in time and > would probably encourage contributing more than rtc. > > Just my opinion. > > Chris > Von: Harbs <[email protected]> > Gesendet: Donnerstag, 18. Juni 2020 22:28 > An: Apache Royale Development <[email protected]> > Betreff: Using PRs for commits > > Hi All, > > I’ve been thinking about the difficulty I sometimes have following changes to > the code and I’m thinking that there would be value to make a practice of > creating PRs when committing changes. > > This would give us: > 1. A clear explanation of the reasoning behind the change. > 2. A good place to discuss changes. > 3. A list of changes for release notes. > 4. Force us to be neater about where and how we commit changes. > > Committers would be able to self-merge although when practical, I’d think it > would be nice to wait a few hours to a day before doing so in case there’s an > issue we didn’t think of. > > Thoughts? > Harbs
