Re: package testing, autopkgtest, and all that
Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"):
> <dep-rant>
> I confess that this seems to be exactly one of those cases where the
> DEP process (should) shine. By putting the specification in a more
> visible place than (only) in an archive package we can give it more
> visibility, easily point developers to it, monitor its acceptance
> status, etc.
>
> Is anyone interested in driving (or co-driving) a DEP about this? The
> current specification looks in good shape already, so what is needed
> is probably just defining criteria for acceptance and launch a final
> round of RFC to fix minor glitches (if any). I'm willing to help
> because I think this topic is very important for us, but I'm not
> willing to do that alone.
> </dep-rant>
I think this would be a fine idea. I'd be happy to help with this
(but my skills may lie elsewhere than what is essentially a form of
marketing ...)
> The need of communication is easy to establish: as this thread has
> shown, very few developers were actually aware of all this valuable
> work. This specification deserves an announcement on d-d-a IMHO, asking
> for both comments and adoption.
Perhaps I should have posted to d-d-a during development.
> The best incentive for adoption in this case is having periodic runs of
> package tests, with reporting. At first glance, I'm tempted to propose
> to use grid archive rebuilds to run tests. Lucas: how much work would it
> be to hack your rebuild scripts and infrastructure to run tests (if
> available)? Lucas' approach to log digging has usually been
> collaborative: once a run is available, we ask on -qa to review
> logs. This is of course not as good as automatic reporting (e.g. a-la
> lintian.d.o), but is a start.
I'd love to see autopkgtest being run on the archive again. As I say
I do test automation quite a lot in my day job now so my desire to
babysit another test automation system is rather less. But I'd be
happy to help and advise.
Ian.
Reply to: