Re: Automatically sending test suite results from buildds to upstream
On Tue, 2005-10-11 at 02:13 +0200, Florian Ragwitz wrote: On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote: SNIP or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. I don't like that solution. Users of the package don't care about the test results so it's useless to bloat the packages with them. Stick the debug files into a seperate -debug package, which nobody will install anyway and just consumes some archive space. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 08:32:51AM +0200, Jeroen Massar wrote: On Tue, 2005-10-11 at 02:13 +0200, Florian Ragwitz wrote: On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote: SNIP or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. I don't like that solution. Users of the package don't care about the test results so it's useless to bloat the packages with them. Stick the debug files into a seperate -debug package, which nobody will install anyway and just consumes some archive space. Packages that nobody will install should not be in the Debian archive. -debug packages only make really sense for a small number of the most high-profile packages. In this case, the extract results from buildd.d.o way is the way to go IMHO. It can be automated too if really needed if you make sure to output specific markers before after the tests run. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 04:07:16AM +0200, Steinar H. Gunderson wrote: On Tue, Oct 11, 2005 at 01:35:06AM +0200, Florian Ragwitz wrote: Therefor I'd like to automatically upload these results to http://smoke.pugscode.org after the packages are built on the buildds. Make your package building fail whenever a test in the testsuite fails? The FTBFS bugs and the buildd logs are sure to tell you what test went wrong. Having a known-bad package built is a generally bad thing anyhow, so you won't really lose much on failing it :-) Pugs is currenyly in a phase of quite early and rapid development. Not everything is ought to at the moment anyway and it's not able to be used in productive environments. I doubt it will ever be because it'll be replaced by the real Perl6 interpreter as soon as it's available. I don't think a single test fail makes a package totally unusable. Regards, Flo -- BOFH excuse #373: Suspicious pointer corrupted virtual machine signature.asc Description: Digital signature
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 12:09:57PM +0200, Jeroen van Wolffelaar wrote: On Tue, Oct 11, 2005 at 08:32:51AM +0200, Jeroen Massar wrote: On Tue, 2005-10-11 at 02:13 +0200, Florian Ragwitz wrote: On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote: SNIP or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. I don't like that solution. Users of the package don't care about the test results so it's useless to bloat the packages with them. Stick the debug files into a seperate -debug package, which nobody will install anyway and just consumes some archive space. Packages that nobody will install should not be in the Debian archive. -debug packages only make really sense for a small number of the most high-profile packages. In this case, the extract results from buildd.d.o way is the way to go IMHO. It can be automated too if really needed if you make sure to output specific markers before after the tests run. I think that's the way to go here. Thanks. -Flo -- BOFH excuse #292: We ran out of dial tone and we're and waiting for the phone company to deliver another bottle. signature.asc Description: Digital signature
Automatically sending test suite results from buildds to upstream
Hello, I'm the maintainer of the pugs package. It features a large testsuite which is run when the package is built on the buildds. The informations generated by this testsuite (in form of html smoke reports) are really useful for upstream authors (that I belong to) to track down bugs, especially on unusual architectures. Therefor I'd like to automatically upload these results to http://smoke.pugscode.org after the packages are built on the buildds. Is it an acceptable behaviour of source packages to upload informations to various places without asking the user for permission like the polularity-contest package for example? Of course, it could be disabled by default and may be activated using environment hooks or other hacks. But that would prevent us from using the buildd results, that are produced anyway, to improve the quality of the upstream software. How should I proceed? Regards, Flo -- BOFH excuse #199: the curls in your keyboard cord are losing electricity. signature.asc Description: Digital signature
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 01:35:06AM +0200, Florian Ragwitz wrote: Therefor I'd like to automatically upload these results to http://smoke.pugscode.org after the packages are built on the buildds. Is it an acceptable behaviour of source packages to upload informations to various places without asking the user for permission like the polularity-contest package for example? Of course, it could be disabled by default and may be activated using environment hooks or other hacks. But that would prevent us from using the buildd results, that are produced anyway, to improve the quality of the upstream software. How should I proceed? Another option is to either leave the information in the buildd log files (i.e. send it to stdout), or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatically sending test suite results from buildds to upstream
On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote: On Tue, Oct 11, 2005 at 01:35:06AM +0200, Florian Ragwitz wrote: Therefor I'd like to automatically upload these results to http://smoke.pugscode.org after the packages are built on the buildds. Is it an acceptable behaviour of source packages to upload informations to various places without asking the user for permission like the polularity-contest package for example? Of course, it could be disabled by default and may be activated using environment hooks or other hacks. But that would prevent us from using the buildd results, that are produced anyway, to improve the quality of the upstream software. How should I proceed? Another option is to either leave the information in the buildd log files (i.e. send it to stdout) That's possible of course, but much more work for me, especially as I plan to release much SVN snapshots in erperimental soon. or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. I don't like that solution. Users of the package don't care about the test results so it's useless to bloat the packages with them. -Flo -- BOFH excuse #169: broadcast packets on wrong frequency signature.asc Description: Digital signature
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 01:35:06AM +0200, Florian Ragwitz wrote: Therefor I'd like to automatically upload these results to http://smoke.pugscode.org after the packages are built on the buildds. Make your package building fail whenever a test in the testsuite fails? The FTBFS bugs and the buildd logs are sure to tell you what test went wrong. Having a known-bad package built is a generally bad thing anyhow, so you won't really lose much on failing it :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
