The idea is that it would be rolled back automatically to the previous
successful nightly. So PRs would be rebased and would address that nightly
test failure, this also links with the manual trigger of CI, which can also
be used to retrigger nightly or benchmarks.
On Mon, Mar 16, 2020 at 11:53
Considering how unstable our PR as well as our nightly jobs have been so
far, is that an assumption we can rightfully make? Also, who'd be
responsible for fixing that branch in case a PR actually breaks a nightly
test?
-Marco
On Mon, Mar 16, 2020 at 7:41 PM Pedro Larroy
wrote:
> The original
The original idea is that the promotion to the other branch is automated by
nightly CI, so it shouldn't have those problems that are mentioned, so
there shouldn't be any manual merging on that branch.
On Wed, Mar 11, 2020 at 7:43 PM Chris Olivier wrote:
> My $0.02
>
> We had this model
+1 to Leonard’s suggestion for just staging individual PRs and running nightly
tests. This seems like a good compromise between maintaining stability (keeping
master from failing as often) and responsibility (nightlies failing on a single
PR are the responsibility of the PR author only). This
The biggest issue in an open source project in my opinion is to find
someone responsible for keeping these two branches in sync. And I don't
mean technically but in the sense of somebody who chases after the issues
that arise in that develop branch.
Looking at this situation today, we regularly
One open source project that uses such staging workflow is cmake. Consider the
recent PR https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4446
They use a robot that understands "Do: test", "Do: stage", "Do: unstage" and
"Do: merge". Nightly tests are run on all staged PRs. A similar bot may
My $0.02
We had this model dual-branch when I was at GE and it was problematic.
Among other things, the two branches would tend to diverge to a large
degree and you ended up just cherry-picking in stuff here and there, which
caused even more problems, as well as the model allows the secondary
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
wrote:
> While the idea of staging seems to be reasonable.
> Most OSS projects
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
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
10 matches
Mail list logo
