mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com>
Subject Re: Protected master needs to be turned off
Date Fri, 01 Dec 2017 19:02:30 GMT
We plan to add the possibility to trigger or stop a build by adding a
comment in the pull request - this will be added after we switched to the
new CI.

Am 01.12.2017 7:25 nachm. schrieb "Mu Li" <muli.cmu@gmail.com>:

> That's how it works before, committers can stop a CI test if it's a simple
> fix, such as typo. But with apache's jenkins server,  it's nontrivial to
> request the permission to stop/start a CI test.
>
> I had a thought about to let the CI be smart enough to only run the tests
> related to the code changes. But I felt it's easier to have committers to
> do it manually. Given the current situation, however, it's probably worth
> spending times to improve the CI instead of requesting changes to the
> repo/CI server.
>
> On Fri, Dec 1, 2017 at 9:49 AM, Tianqi Chen <tqchen@cs.washington.edu>
> wrote:
>
> > I think we are still using CI to catch bugs. And we should take caution
> > when merging something that CI did not catch up due to the response time.
> > This do not contradict what comitter can do with their best judgement.
> For
> > example, I would normally switch CI off and merge simple typo fixes. If
> the
> > fix merged causes problem, you still get CI to report it maybe a few
> hours
> > later.
> >
> > The bottom line is that comitter get these information as feedbacks and
> > they use their best judgement when do so. Most of the time when unsure, I
> > simply wait for CI to finish
> >
> > Tianqi
> >
> >
> > On Fri, Dec 1, 2017 at 9:41 AM Mu Li <muli.cmu@gmail.com> wrote:
> >
> > > Totally agree that CI is useful. Actually, I wrote the jenkinsfile and
> > > setup the jenkins server before moving to apache server. I just mention
> > > that we cannot rely on the CI test. It currently covers operator
> > unittests
> > > and regression test on several cnns. But the code coverage isn't great.
> > If
> > > a PR touches the core system, the best practice today is still code
> > > reviewing. Otherwise, such as a PR is mainly about examples, the CI
> often
> > > doesn't help so we just waste machine times.
> > >
> > > I think checking the exact code coverage is on the roadmap, but I don't
> > > know if we have any progress on it.
> > >
> > > On Fri, Dec 1, 2017 at 6:19 AM, Pedro Larroy <
> > pedro.larroy.lists@gmail.com
> > > >
> > > wrote:
> > >
> > > > CI catches problems all the time. I don't think many of us can afford
> > > > to build all the flavors and architectures in their laptops or
> > > > workstations, so we have to rely on CI to catch all kinds of errors
> > > > from compilation errors to bugs plus regressions, specially in a
> > > > project which has so many build flavors.
> > > >
> > > > I have had this experience in big projects several times and I can
> > > > tell you it's always the same.
> > > >
> > > > So from extensive software development experience I write that we
> will
> > > > be able to develop and merge much faster once we have a reliable CI
> > > > running in short cycles, any other approach or shortcuts is just
> > > > accumulating technical debt for the future that somebody will have to
> > > > cleanup and will slow down development. Is better to have a CI with a
> > > > reduced scope working reliably than bypassing CI.
> > > >
> > > > This is irrespective of using dev to merge or unprotected master.
> > > >
> > > > We can't afford to have increased warnings, bugs creeping into the
> > > > codebase going unnoticed, build system problems, performance
> > > > regressions, etc. And we have to rely on a solid CI for this. If we
> > > > are not ready for this, we should halt feature development or at
> least
> > > > merging new features until we have a stable codebase and build
> system.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message