continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud HERITIER" <aherit...@gmail.com>
Subject Re: Trusting in our own dog food
Date Wed, 17 Jan 2007 21:05:46 GMT
Is it normal that the projects list is empty when we aren't logon ?

http://maven.zones.apache.org:8080/continuum/groupSummary.action

Arnaud

On 1/17/07, Brett Porter <brett@apache.org> wrote:
>
> Ok, fair enough. I've left it on, and made it use a different local
> repository.
>
> I'd say once we release Continuum 1.1 and are happy it is stable
> enough to use, we can turn this off.
>
> On 15/01/2007, at 11:02 PM, Trygve Laugstøl wrote:
>
> > Brett Porter wrote:
> >> so... you're saying you don't trust our dog food? :)
> >
> > No, I'm saying it's there to verify the dog food. If there is no
> > discrepancies between what the cron is saying and the C instance is
> > saying, it's good. If there is an discrepancy it's not good.
> >
> > It will be more a tool to verification tool that a CI (but that
> > might be two sides of the same story :)
> >
> > --
> > Trygve
> >
> >> The only thing it tests differently is:
> >> - works by cron, whereas continuum might go down/hang/something
> >> else (which is something we should work on fixing if it does,
> >> rather than rely on ci.sh)
> >> - runs a reactor (can add that as a less frequent build execution
> >> in continuum too, though).
> >> So, I don't see any reason to keep it - wdyt?
> >> - Brett
> >> On 11/01/2007, at 7:57 PM, Trygve Laugstøl wrote:
> >>> Brett Porter wrote:
> >>>> Folks,
> >>>> I'd like to turn off continuum_ci.sh and instead only use
> >>>> Continuum itself to do CI for Continuum. Any objections?
> >>>
> >>> I don't see why it should be turned off, but perhaps the
> >>> automatic notifications can be turned off or just send failures.
> >>> That way it would verify the product (it will in itself be an
> >>> integration test) because if the Continuum instance says that
> >>> something is failing, you should expect an email saying the same
> >>> right after. Or at least you can check the logs directory if
> >>> you're suspecting some other failure.
> >>>
> >>> --
> >>> Trygve
>

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