[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: package testing, autopkgtest, and all that



On Thu, Jan 27, 2011 at 02:45:57PM +0000, Ian Jackson wrote:
> > Ian: would you mind summarizing the status of that effort and
> > comment on whether, in your opinion, people interested on this topic
> > should continue from there or start over?
> 
> Sure.  autopkgtest (the codebase) isn't very big but it contains
> several interlocking parts.  The key parts are:

Thanks a lot for this summary and for posting the specification (I've
some comments about it, that I'll post separately). The situation looks
much better than I thought; I believe it was just at an "abandoned
draft" stage and I wouldn't be surprised if others think the
same. Thanks for the good news!

It seems to me that, at this point, what we need is "just" adoption to
test drive specification and code. Also, we probably need to define some
mid/long-term success criteria like "integration into policy" (which as
usual will follow adoption).

<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>

No matter the mechanism used to encode the spec, adoption will be driven
by two main ingredients: (1) communication, (2) incentive.

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.

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.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams

Attachment: signature.asc
Description: Digital signature


Reply to: