[Ecls-list] Testing re-organisation

[Daniel Kochmański]

Hello,

I think approch with cloning git repository would be optimal. On the
other hand, I think duplication of effort by keeping separate ansi-tests
repository would be a waste, because each distribution can benefit from
common lisp ansi tests.

Original ansi-cl-tests repository has been recently forked by Robert Strandh:
https://github.com/robert-strandh/ansi-cl-tests, SICL creator, and it
has a few recent commits, which are relevant to ECL (I'm was working
lately on pstef/shiftf/rotatef bug pointed by Robert), and I think it's
a way to go

I'd be for option number two, because person, who is capable of building
ECL and wants to test it probably *has* git. On the other hand github
has "download as tarball" option as well (i don't know, just guessing).

Updating tests/Makefile is important, also to be able to do regression
tests, each version of ECL should be probably shipped with it's current
results (?) - what do you think?

Other very important thing in my opinion is something not related to
fixing something - rather describing. We lack proper documentation about
testing process - we have two testing methods, one with cl-test-grid,
and second with ansi-cl-tests. Neither is described on wiki, or any
README, what is a big issue, if someone is willing to do the testing,
but has no idea how. I believe that wikipedia entry is something, we
should do in the near future.

Open question also persists about how to test ECL on various operating
systems - even if we have great support from people doing it on
Linux/Darwin/Windows, nobody does it on other unix machines, yet we have
a few bugs if you look at bug reports (on sf.net for now).

Best regards,
Daniel

Evrim Ulu writes:

> Try submodule approach.
> http://git-scm.com/book/en/v2/Git-Tools-Submodules
>
> evrim.
>
> On Mon, Apr 6, 2015 at 9:47 PM, Roger Sen Montero <roger.sen at gmail.com>
> wrote:
>
>> Daniel,
>>
>> Just not to duplicate effort, what do you have in mind for the testing
>> part of ecl? Currently tests are downloaded from Sourceforge (and are not
>> part of the distribution), the makefile used is less than optimal and the
>> output of the results is difficult to manipulate.
>>
>>  So what is the plan for the test files? I see three possible options:
>>
>>  1) Include them in the main distribution/git repository.
>>
>>  PROs: no external dependencies.
>>  CONs: bigger source tar.gz. // test linked to downloaded ecl version.
>>
>>  2) Include them in a secondary git repository and do a git clone before
>> running the tests.
>>
>>  PROs: being able to update tests for all existing ecl versions. // we
>> don't increase .tar.gz
>>  CONs: dependency with git.
>>
>>  3) Move the tests to a secondary git lab repo and download as we do it
>> today but from the .tar.gz in gitlab.
>>
>>  PROs: being able to update tests for all existing ecl versions. // we
>> don't increase .tar.gz
>>  CONs: maybe some kind of bandwidth limit with gitlab?
>>
>>  Also there's the need to update tests/Makefile, but this is a trivial
>> tasks.
>>
>>  Comments? I'm happy to create a branch and do this changes.
>>
>> --
>> Roger Sen Montero
>> roger.sen at gmail.com
>> +34 649 975 570
>>
>>
>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live
>> exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
>> event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> Ecls-list mailing list
>> Ecls-list at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ecls-list
>>
>>

-- 
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel

"Be the change that you wish to see in the world." - Mahatma Gandhi