On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt <spudan...@gmail.com> wrote:
> That would simplify accepting PRs since the uniformed will probably > continue to submit against master. This would make that behavior > workable. Semantically, I would have to wrap my head around the notion > that the master is not the master but a development branch. But even > old dogs can learn new tricks with enough time. On the issue of whether master should be a dev branch or not, my 2 cents: I think we should strive to keep master as close to "releasable" as possible at all times, do development on dev branch(es), and create release branches to which changes are only made by backporting from master. I think this is closer to a CI/CD (Continuous Integration / Continuous Delivery) style. Why we would want that: (1) I think most users will assume that master should be buildable and usable. (2) If master is buildable and usable at all times, it will probably get wider testing and therefore any new problems should be detected quickly. (Case in point: I caught a few issues the same day they were introduced by using master every day.) (3) If master becomes a dumping ground for any changes and then we have to sift through them to decide what to port to a stable branch, it might become a mess. I think it's best to review before it comes into the tree, and then if approved, bring it in decisively. Just food for (collective) thought. Nathan
