Is it time to start regression testing yet?

[C. Florian Ebeling]

> I notice it flagged the mldonkey build as failed, but in fact it was one of
> mldonkey's dependencies which failed. Perhaps there is a way that could be
> made more clear in the interface.

Yes, it did mark mldonkey as failure, but take it as what it really
is: a change event picked up in the subversion, which triggers a build
of the package in question. If that gives you an error exit code, it
is marked as failure. This is obviously not necessarily the
maintainer's fault. The whole thing is targeted to an developer
audience to give instant feedback on changes, and should not be
misunderstood as a tool for MacPorts users in the broader sense.

That said, from the user's perspective, it might not make much of a
difference, because if you where to install your package and it fails,
it is the exact same experience and consistent with what Portmill
shows for it.


> Juan (jmpp) had always said that a prerequisite for a build/test system was
> implementing the port logging proposal:
>
> http://trac.macports.org/wiki/LoggingProposal

I would disagree. This build system does what you would otherwise do
manually: build a certain port for test reasons and watch the debug
output and end result. If the output gets improved, all the better. I
don't see much of a connection necessarily. It might be interesting,
though, if the logging would include some kind of event API, then a
build server would see more information that exit code and brittle
regexping of output, to which one otherwise would have to resort. That
would e.g. make it much easier to do what you asked for above, i.e.
figure out more about the reason of the build failure, the build
phase, and maybe a distant dependency which is really the culprit.


> And this is the project Dmitry (enl) has been approved to work on for this
> year's Google Summer of Code:
>
> http://trac.macports.org/wiki/enl
>
> http://trac.macports.org/browser/branches/gsoc09-logging
>
> Have you coordinated with him? We don't want duplication of effort. Your
> work is clearly logging something because the logs are appearing on your web
> site. If this is not integrated with the MacPorts Tcl code, perhaps you can
> assist Dmitry in doing so. If you and Dmitry finish the logging task early
> I'm sure there are other tasks we can have him do for the rest of the
> summer.

I think it can only help to have better output, but no problems
really. I didn't read the proposal though.

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com