On 18/05/16 01:44, Kent Fredric wrote: > On 18 May 2016 at 12:35, M. J. Everitt <m.j.ever...@iee.org> wrote: >> Yes, whilst that's a special case, it would be desirable to collaborate >> with another maintainer/team/project to devise a test schedule that was >> independent from the target language, if possible. But there will always >> be exceptions and issues and such with these things .. :/ > > In some of these cases, the things I'd be testing have to rely on Perl > Modules *because* it has to track how those specific modules respond > to the code in question. > > For instance, to check we're doing our version normalisation > correctly, we have to use the upstream reference version of Perl's > version handling code directly. > > *NOT* doing this results in significant problems, both in our failure > to perfectly map upstreams implementation in a different language, and > in our ability to keep our implementation in consistency with upstream > changes. > > And we have already suffered this problem specifically in euscan, > where the euscan project implemented the version interpretation logic > manually, and did so hilariously wrong, and as a result, thinks newer > versions are older versions a lot of the time, and vice versa. I've > attempted my own implementation of upstreams logic *better* than I > think euscan does it, but I'm trapped in the reality where I have *no* > objective way of knowing if it in fact, represents upstreams logic > correctly. > > The simplest thing to say here is "implementing it in a non-target > language is often enough the wrong choice". > > Similarly, I've made the mistake of trying to understand and interpret > ebuilds statically without using bash .... that's a road to nowhere. > Even using bash is a bit tortured because I can't understand how an > ebuild works without reimplementing all the EAPI parts in bash or > relying on some portage version of the same ( which is extremely not > easy to use outside of the portage tools ). > Yes, I get where you're coming from. I think many of the language and language-plugin ebuilds are going to suffer from similar problems for exactly the reasons you describe. It does make the prospect of a good, over-arching QA/CI system quite challenging (but not impossible) to achieve .. !!
signature.asc
Description: OpenPGP digital signature
