Hi Tatiana,

> I afraid that I am not familiar with typical Hydra use cases

Generally, the continuous integration process should enable developers
to get feedback about the effects of their changes.

This means that as soon as a commit is made, usually an evaluation of
the build source on the continuous integration server starts.

(Sometimes there are exceptions to this (for example in order to not overload
the build servers) - but generally it's true)

For a new evaluation, as a developer I'd like to know:

* Are now more packages broken than before?  Which ones?
* Are now more packages working than before?  Which ones?
* Do some packages work on more architectures than before? Fewer?
* Is the build server still building my change?  Or is it done and I
can trust that the information I see is now complete?  If not,
what is it building now or later?

"before" means "with the previous evaluation" or "with some specific past
evaluation" or "in another branch".

I think this would be the most basic functionality.

More advanced functionalities would include automatic tracking on the reason
of the failure:

* If it's dependency failure, specifically mark this package so I know I don't
have to fix this package - I have to fix a package this one depends on (which one?).
* What kind of failure is it? What's the latest non-noise error message in the
build log?  Display suggestions on what to do about it.

What do you think?

>4. Add additional information about previous builds (latest successful,
>first broken, etc) on this build page. For this feature, we need to extend
>database requests functionality.

Sounds good.