Re: Integrating Anthill with a Problem Report systyem?

Eric Minick wrote:
> Marcio,
> 
> Another approach to limiting the constant email problem would be to have 
> an option to only send out emails on the first failure. Anthill can 
> continue spinning it's wheels on the 30 minutes schedule trying to get a 
> build out, but not harass people about it. Would that make sense for you?


   Another option is to have Anthill detect if files changed since the 
last build attempt instead of the last successful build. This would also 
cut the useless number of emails etc in the case where a build breaks 
and stays broken for a while. No wheel spinning in vain. So, we have 3 
options so far:

1) (your sugestion) Having a UI flag to tell Anthill to only email on 
the 1st failed build. ANthill still spins its wheels in vain in th ecase 
of a broken build that takes a while to be fixed.

2) (my suggestion) Having a UI flag to make it switch to stoppedSchedule 
when a build fails. This forces manual intervention on a broken build, 
which is what we want in one scenario. A person will come and enter a PR 
in Bugzilla etc. When the PR is closed, the schedule is switched back.


3) (my suggestion) Having a UI flag (2 radio buttons) to tell Anthill to 
detect changes files since a) last successbuild; b) lat build attampt. 
Currently Anthill only supports b). This forces manual intervention on a 
broken build, which is what we want in one scenario. A person will come 
and enter a PR in Bugzilla etc. When a new file is commited (hopefully a 
fix) the build automatically kicks in.


   In fact I think that all 3 are needed to make Anthill flexible and 
fit more workflow scenarios.


marcio