harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: svn commit: r637937 - in /harmony/enhanced/jdktools/trunk/modules/jpda: ....
Date Thu, 20 Mar 2008 05:18:55 GMT
On 3/19/08, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Stepan Mishura wrote:
> > On 3/19/08, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> >> Hi Stepan,
> >>
> >> Thanks for fixing that! I did do a build on Linux at the time, but it
> >> was a sequential build from an already existing workspace so it must
> >> have missed that change somehow. Ill build from scratch next time to
> >> make sure!
> >> I do watch the alerts list, and I fixed the build break I saw (the one
> >> you raised initially), but received no further mails indicating a break
> >> on Linux x86. I take it a mail only gets sent when the state of the
> >> build changes? So if there is a second break (as in this case) no mail
> >> is sent because the build state does not change?
> >
> > Yes, it is. If the build is broken than only initial notification is
> > sent, no repeated notifications are sent.
> >
> > It is expected that once committers see a notification about build
> > breakage all commits are stopped and everybody wait when the build is
> > fixed and notification about build recovery is received - I think
> > everybody should know that if the build is broken no tests are run. We
> > tried to establish a practice with stopping commits but it seems that
> > people don't like to follow it :-)
> Like you say, if somebody breaks the build (via the alert notifications
> etc.) then it is their duty to fix it (i.e. see the successful message).
> It's pretty simple.

Yes, that true.

But you missed my point - usually (not this particular case) there are
dozens of commits between build breakage and its recovery. IMHO that
definitely means that people don't pay attention to alerts and don't
look at the integrity page.
Also it may mean that:
- commits are not monitored (IOW, the last/fresh code from repository
is not used)
- unit tests are not run
- regressions are not evaluated early.
(The last two points are nightmare for QA engineer :-))

Seriously speaking, I think we established good (not perfect, but
anyway I do believe it is good) testing process to assists developer.
Say, a developer doesn't need to run all suites included into
integrity testing on all platforms. She/he may run only selected tests
(I assume that most of developers test changes in this way) on couple
of platforms(Linux/Windows) and if everything pass then changes are
committed. And she/he have opportunity to see all tests results on all
platforms pretty soon(~5 hours). Wow!
... and what are reasons to ignore such opportunity?


> Regards,
> Tim

View raw message