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