2010/5/13 Jonathan Leto <[email protected]> > Howdy, > > I would like to say that I share japhb++'s slight concerns in copying > in code without original copyright notices. I wanted Tapir to live in > ext/ in the same way as pmichaud++'s NQP. I think fperrad added some > features and renamed various files, so it is hard to say what > percentage of code Tapir on github and TAP::* in parrot core share. If > fperrad++ could describe what modifications he made, that would be > very helpful. My hope would be to incorporate all his new > modifications, with his permission, into the Tapir on github and then > get Tapir installed into ext/. > >
I did a mistake when I reused for a fakexecutable the name 'tapir' from a project which seems abandonned since 3 months (in http://github.com/leto/tapir, last commit on January 26, 2010) I wrote a TAP consumer library in PIR, in the following files (and their histories) : http://trac.parrot.org/parrot/browser/trunk/runtime/parrot/library/TAP/Parser.pir http://trac.parrot.org/parrot/browser/trunk/runtime/parrot/library/TAP/Harness.pir http://trac.parrot.org/parrot/browser/trunk/runtime/parrot/library/TAP/Formatter.pir http://trac.parrot.org/parrot/browser/trunk/tools/dev/tapir.pir http://trac.parrot.org/parrot/browser/trunk/t/library/tap_parser.t These files contain no code fragment from http://github.com/leto/tapir. I did a partial "manual compilation" or a port (Perl5 to PIR, Perl5 regex to PIR) of some Perl5 modules from CPAN : http://search.cpan.org/~andya/Test-Harness/ http://search.cpan.org/~wonko/TAP-Harness-Archive/ I reuse from original Perl5 modules : - the same classes/namespace names & inheritance hierarchy - the same method/function names - the design of the TAP parser with a customer FSM - some TAP fragments in the test suite. For this reason, these files contains links to original Perl5 modules in CPAN. In the future, I'll continue this "manual compilation" with TAP::Formatter::Color and TAP::Formatter::Console::ParallelSession parts. Currently, I do the same thing with the Perl5 modules URI & LWP (coming soon). Somebody who really read my code, can not speak of fork or copy+tweaked like I read in the referenced IRC log. As I already wrote in http://lists.parrot.org/pipermail/parrot-dev/2010-April/004110.html if needed the current fakexecutable 'tapir' in Parrot tree could be renamed 'parrot-prove'. Note: this TAP library is also used by the distutils library and t/harness.pir which is also a port (Perl5 to PIR) of the t/harness. François > With this setup, developers have the freedom to work on Tapir and > Parrot gets to choose exactly which version of Tapir it considers > stable and wants to tie to a specific release. > > As it seems that Parrot is going in the direction of git, slowly but > surely, NQP and Tapir can be submodules, so that parrot.git will > control the exact commit of each that it wants, and there will not be > any "copy into parrot and commit" stuff. A git submodule is roughly > equivalent to an svn external. > > Duke > > > > On Thu, May 13, 2010 at 11:26 AM, Geoffrey Broadwell > <[email protected]> wrote: > > Starting at http://irclog.perlgeek.de/parrot/2010-05-13#i_2327099 we had > > a short discussion regarding the fact that at least twice recently code > > from an external project has been copied directly into the parrot > > repository, without retaining a copyright notice or reference to the > > original project/repo that the code came from. > > > > As Coke said, "We cannot just copy code we don't own into the repo and > > claim it." I think in both cases (code from Plumage and from Tapir), > > neither of the owners had a problem with Parrot using the code -- in > > fact we had both hoped to eventually keep snapshots in ext/ as nqp-rx > > does today -- but that wasn't the point. > > > > As a matter of copyright management we can't just import code from other > > projects without a copyright notice (and probably a link to the original > > project). As a matter of supportability it's important to keep in touch > > with the upstream project regarding bugfixes and the like. And as a > > matter of good manners, it's nice to at least talk to the original > > project before copying the code. At the very least they may suggest how > > they'd prefer it be done, or in fact already have a process for working > > with downstream projects harmoniously. > > > > Does PaFo have an official policy on copying external code? (Assuming > > the license is already compatible, of course.) > > > > > > -'f > > > > > > _______________________________________________ > > http://lists.parrot.org/mailman/listinfo/parrot-dev > > > > > > -- > Jonathan "Duke" Leto > [email protected] > http://leto.net > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
