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
