[Pkg-ruby-extras-maintainers]

[Esteban Manchado Velázquez]

Hi all!

On Thu, Nov 24, 2005 at 12:36:33PM +0100, Lucas Nussbaum wrote:
> [...]
> > >     Just one comment: wouldn't it be better having all the dev files
> > > documentation in a version independent package, like libxxxxx-ruby-dev
> > > (instead of libxxxxx-ruby1.8-dev)?
> > 
> > I think this is better too.  The dummy -ruby package is meant for the
> > developer and so is the -ruby-doc package.  Besides that, the
> > documentation isn't Ruby version dependent (in AFAIK all cases).
> 
> As said in my other mail, examples are ruby-version-dependant if they
> include a shebang.

    But if that's the only difference, I wouldn't make a version for each Ruby
interpreter version. In that case, on top of that, we would have to make them
(I don't think upstream usually ship separate examples for each Ruby version).
I simply don't see the point, the user can call them as "ruby1.x example.rb"
if he wants to.

> > > > About unit tests: it would be great to have a common architecture to
> > > > deal with our unit tests. This way, one could run a script on a regular
> > > > basis to check that all his installed packages still work correctly.
> > > 
> > >     I'm not sure I like this. I would prefer using the Ubuntu proposal (or
> > > something similar) for package testing, and somehow plug the own library unit
> > > tests into the distribution package framework. After all, the package
> > > maintainer is basically who needs/is interested in package testing...
> > 
> > Yes, the unit tests need to be ran while packaging.  If unit tests are
> > available for a library then this is great for the "package testing
> > before upload".  I don't think a user/developer is going to rerun the
> > tests to find the same results as the maintainer has.
> 
> This requires manual copying of the test scripts to the debian/tests dir
> by the maintainer. This is error-prone, etc.

    Not necessarily. In fact, I would try to solve it in a generic way, with
the CDBS or whatever.

> The Ubuntu proposal is flexible enough to allow to store tests in a -dev
> package. Also, another reason for not storing tests in the source package is
> that the Ubuntu proposal is not implemented yet.

    I'm not sure I understand ("not storing tests in the source package"?).
What are you against exactly? The only thing I'm saying is that I don't like
implementing something on our own (the "command architecture to deal with our
unit tests" you said; it's still quoted to give context, perhaps I didn't
understand you). I would much prefer using something already done, and
"standard", if good enough. And it's probably going to be easy, plugging the
own package unit tests to the Ubuntu testing framework.

> I think test scripts often can be useful as documentation, especially
> when example scripts are not provided.

    Yes, perhaps in some cases, but, in how many of them? In any case, perhaps
we could provide them as documentation, but not try to execute them or
otherwise treat them as code.

> Also, I personally would like to be able to run the tests on all ruby
> packages on a regular basis.

    "all ruby packages" = "including those not packaged by you", right?

> The fact that the package works at build
> time doesn't mean that it will continue to work. For example, when rake
> 0.6.0-1 was uploaded, it was working just fine. But when ruby 1.8.3 was
> uploaded, a change in fileutils broke rake (see bug #336937). If rake
> came with a test suite, and if somebody had been running it regularly,
> this would have been easily picked up.

    I think that's our duty. I don't see the point of letting _everyone_ (as
opposed to each package maintainer) continually run the tests. If you see
something bad, and you know what packages are involved, you can always run the
tests once for those packages.

    One more question: if we follow the Ubuntu proposal and make all Ruby
packages testable with it, it will probably be very easy to test all of them
at once. Perhaps even Debian will have an automated testing infrastructure
that will do what you describe, but in a centralized fashion... or do you see
any difference?

    Regards,

-- 
Esteban Manchado Velázquez <zoso at debian.org>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20051127/bf281828/attachment.pgp