Second to not introduce a dev branch. We should try to improve our release process instead and avoid another branch that may introduce confusion around the source of truth.
On Wed, Mar 11, 2020 at 8:39 PM Tianqi Chen <tqc...@cs.washington.edu> wrote: > While the idea of staging seems to be reasonable. > Most OSS projects choose not to do so because having a complicated staging > will likely confuse the contributors, and increase the change of > divergence(between dev and master). > > Given that we have a release model, so in some sense the release itself > serves as a staging pt. > A good approach would simply setup the nightly if necessary strive to fix > regressions and make sure the formal release addresses the issues. > > TQ > > On Wed, Mar 11, 2020 at 5:32 PM Pedro Larroy <pedro.larroy.li...@gmail.com > > > wrote: > > > Hi > > > > I talk to some people about this and they thought it would be a good > idea, > > so sharing it here: > > > > I would propose to use a staging or "dev" branch into which nightly & > > performance tests are done periodically and then this branch is merged to > > master. The goal of this workflow would be to avoid having regressions > and > > nightly failures creeping into master. PRs would get merged into dev and > > dev promoted periodically / nightly into master. > > > > The names can be swapped as well, between dev and master, so PRS get > merged > > into master and it doesn't change the workflow, and staging is the branch > > where nightly changes are merged to. > > > > Have this been considered? > > > > Pedro. > > > -- Yuan Tang https://terrytangyuan.github.io/about/ <http://twitter.com/TerryTangYuan> <https://terrytangyuan.github.io/about/>
