Re: Proposal Suggestion - Test::Run

[chromatic]

On Wednesday 05 July 2006 23:02, Shlomi Fish n wrote:

> I don't see using the X11 licence for my software as anti-social. Like I
> said, anyone can easily fork it as a software of a different licence.

Supposing you actually find a mentee and TPF actually does fund this project 
and this code is substantially better than Test::Harness such that it is an 
obvious candidate for inclusion in the Perl core.

It must be under the Perl license.

Now there is a fork of a fork, as the code that makes it into the core has an 
incompatible license with your fork.

(Do NOT assert, yet again without proof or a demonstratable understanding of 
the problem, that there exists a trivial solution.  The linking clause of the 
GPL is hardly a new or poorly understood legal invention, for example.)

I am not sure what to call this, but I do know that it is not a viable long 
term strategy for anyone else.  How is your refusal to follow community norms 
(or, I suppose, to work with an amenable maintainer) anything *but* 
anti-social?

I suppose "copy-and-relicense forking" is as good a description as any.

That is not a complimentary description, by the way.

-- c

Re: TAP::Harness

[Michael G Schwern]

On 7/1/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:

As my flight is delayed I'll try to make a stab at posting up the basic design.


The whole point of replacing the Perl QA wiki was to have a public
place for the TAP::Harness design to live. :)

http://perl-qa.yi.org/index.php/TAP::Harness

The sources and runners work.  I started on the parser and then
stopped when I realized it would work better with a separate lexer.
The responsibilities of the parser vs the aggregator are still a bit
fuzzy as is exactly what goes into an event.  But hopefully there's
enough there to give a clearish idea of where I'm headed, what its
potentially capable of and to warn me alway from any horrible design
mistakes.

Re: Proposal Suggestion - Test::Run

[Shlomi Fish n]

On Thursday 06 July 2006 00:36, Jonathan T. Rockway wrote:
> Two comments, pretty much agreeing with chromatic and Ricardo:
>
> 1)  How would this proposed module benefit the perl community? Why 
> can't you fix things in Test::Harness and send the patch in?  If you fix
> deployed modules, everyone wins.  If you write your own module, it sits
> on CPAN unused.
>
> What exactly is wrong with Test::Harness, anyway?  The development team
> is pretty agreeable, the code is good, the module works, etc.  Is there
> some large problem I'm missing?  (A problem so large that TPF needs to
> *pay* someone to fix it!?)
>

I've answered some of these things in the following links:

http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/
http://use.perl.org/~Shlomi+Fish/journal/27467
http://use.perl.org/~Shlomi+Fish/journal/27887

Also see my other replies to this thread:

http://www.mail-archive.com/perl-qa%40perl.org/msg05987.html

And also the resource that Schwern pointed to:

http://www.mail-archive.com/perl-qa%40perl.org/msg06014.html

> 2) If you use GPL'd code in an MIT-licensed app, the entire app becomes
> GPL.  I don't think you can say, "this requires xyz GPL'd code, but if
> it didn't it would be MIT".  It's GPL by virtue of requiring GPL code.
> (Hence the accusation that the GPL is 'viral' or whatever.)  IANAL, but
> this is my understanding from reading the license, the FSF's site, etc.
> If the code isn't derived, though, feel free to MIT license it.  

There is a difference between derived code and inclusive code. The code that 
originated from other people's code was kept under the same licence 
(GPL+Artistic in this case). I also disclaimed any explicit ownership of it. 

OTOH, the code that was written from scratch and was my original code was 
licensed under the X11 licence, because it did not include anything else.

> (The 
> fact of the matter, though, is that Perl uses the Perl license.  I don't
> really love the Artistic license, but I release my perl code under the
> dual license because Everyone Else Does.  

I don't like doing everything only because everyone else does them. I like to 
think for myself what is the best course of action and long time strategy. 

> It makes everything work 
> nicely and builds community too  :)
>

I don't see using the X11 licence for my software as anti-social. Like I said, 
anyone can easily fork it as a software of a different licence. It's also 
more permissive than the GPL+Artistic licence (and much less problematic than 
the Artistic 1.0 licence, which some people don't even consider as 
free-as-in-speech.)

So far I've released all the software (Perl or otherwise) for which I had a 
choice under the Public Domain or X11 licence.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Test::Builder feature request...

[Michael G Schwern]

On 2/9/06, Geoffrey Young <[EMAIL PROTECTED]> wrote:

> This works:

yes, excellent randy.  thanks for that.  it still seems a little hackish but
that's ok - hackish works for me if it means I can do what I want and nobody
else needs to do extra work :)

I made some tweaks to your format and added a few minor notes here

  http://people.apache.org/~geoff/test-more-separately.tar.gz


A less hackish version of plan.t is...

 use Test::More;
 my $TB = Test::More->builder;
 $TB->no_ending(1);

 plan tests => 3;

 print qx!perl t/response.pl!;

Re: CPAN and META.yml: no_index dir vs directory

[Johan Vromans]

> > no_index/dir 13
> > no_index/directory 1397
> > private/directory40

> As for "dir", I'm three of the 13, 

I'm another three of the 13, and I'll switch to 'directory' as of the
next upload.

-- Johan

Re: CPAN and META.yml: no_index dir vs directory

[David Golden]

Andreas J. Koenig wrote:

The page is there, http://thepierianspring.org/perl/meta/, but does
not provide direct statistics so I made up my own.

no_index/dir 13
no_index/directory 1397
private/directory40

David's D/DA/DAGOLDEN/Perl-Dist-Vanilla-5 used both dir and directory:)

Those who used just "dir" were ignored up to now:

 B/BL/BLM/Win32API-Registry-0.27
 B/BW/BWARFIELD/NRGN/Test-AutoLoader-0.03
 D/DA/DAGOLDEN/Object-LocalVars-0.15
 D/DA/DAGOLDEN/Object-LocalVars-0.16
 D/DA/DAGOLDEN/Perl-Dist-Vanilla-4
 G/GU/GUIDO/Test-Unit-GTestRunner-0.03
 G/GU/GUIDO/Test-Unit-GTestRunner-0.04
 J/JV/JV/EekBoek-0.91
 J/JV/JV/EekBoek-0.60
 J/JV/JV/EekBoek-0.61
 R/RC/RCAPUTO/POE-0.3502
 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801


Well, I think that suggests pretty definitively that "directory" needs 
to be added to the spec, at least, to reflect de facto usage.


As for "dir", I'm three of the 13, so discount those.  I'm not sure 
that's worth adding to CPAN.  Maybe it calls for dropping "dir" from the 
spec unless anyone else knows who's using it.


Regards,
David

Re: CPAN and META.yml: no_index dir vs directory

[Andreas J. Koenig]

> On Wed, 5 Jul 2006 21:39:06 -0500, Ken Williams <[EMAIL PROTECTED]> said:

  > On Jul 5, 2006, at 7:47 PM, David Golden wrote:

 >> Some potential options:
 >> 
 >> (a) Add "directory" as a synonym to the spec and add "dir" as
 >> something that CPAN sites recognize.
 >> 
 >> (b) Change the spec to "directory" -- if CPAN sites are the only
 >> real user of META.yml no_index, then the pain should be minimal.
 >> 
 >> (c) Change CPAN sites to follow the spec, despite breaking many
 >> distributions' current indexing.


  > Randy Sims keeps some statistics on the META.yml files that exist on
  > CPAN, perhaps he could tell us the relative frequencies of 'dir' vs.
  > 'directory' in the wild?

The page is there, http://thepierianspring.org/perl/meta/, but does
not provide direct statistics so I made up my own.

no_index/dir 13
no_index/directory 1397
private/directory40

David's D/DA/DAGOLDEN/Perl-Dist-Vanilla-5 used both dir and directory:)

Those who used just "dir" were ignored up to now:

 B/BL/BLM/Win32API-Registry-0.27
 B/BW/BWARFIELD/NRGN/Test-AutoLoader-0.03
 D/DA/DAGOLDEN/Object-LocalVars-0.15
 D/DA/DAGOLDEN/Object-LocalVars-0.16
 D/DA/DAGOLDEN/Perl-Dist-Vanilla-4
 G/GU/GUIDO/Test-Unit-GTestRunner-0.03
 G/GU/GUIDO/Test-Unit-GTestRunner-0.04
 J/JV/JV/EekBoek-0.91
 J/JV/JV/EekBoek-0.60
 J/JV/JV/EekBoek-0.61
 R/RC/RCAPUTO/POE-0.3502
 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801

-- 
andreas

Re: CPAN and META.yml: no_index dir vs directory

[Ken Williams]

On Jul 5, 2006, at 7:47 PM, David Golden wrote:


Some potential options:

(a) Add "directory" as a synonym to the spec and add "dir" as  
something that CPAN sites recognize.


(b) Change the spec to "directory" -- if CPAN sites are the only  
real user of META.yml no_index, then the pain should be minimal.


(c) Change CPAN sites to follow the spec, despite breaking many  
distributions' current indexing.



Randy Sims keeps some statistics on the META.yml files that exist on  
CPAN, perhaps he could tell us the relative frequencies of 'dir' vs.  
'directory' in the wild?


 -Ken

Re: Proposal Suggestion - Test::Run

[Michael G Schwern]

On 7/5/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote:

1)  How would this proposed module benefit the perl community?  Why
can't you fix things in Test::Harness and send the patch in?  If you fix
deployed modules, everyone wins.  If you write your own module, it sits
on CPAN unused.

What exactly is wrong with Test::Harness, anyway?


At least this much I can answer.
http://perl-qa.yi.org/index.php/Test::Harness

IMHO multiple, competing TAP parsers is healthy.  Whether or not TPF
should pay for it is another thing entirely.

Re: The new wiki

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Thanks to Tyler MacDonald and yi.org we now have a brand spanking new
> wiki!  http://perl-qa.yi.org/ is its location, we'll worry about
> getting more official domains later.

Since I set up my own server for (then nx, now yi).org 8 years ago
and started doing the dynamic DNS thing, my hope was to be able to give
something back to the hackers in the open source community that have already
given me more than a lifetime's worth of value. Perl/CPAN in particular has
made my life both more enjoyable and profitable. I'm glad that the server is
fulfilling it's use; thanks to you guys for doing what you're doing! :)

- Tyler

The new wiki

[Michael G Schwern]

Thanks to Tyler MacDonald and yi.org we now have a brand spanking new
wiki!  http://perl-qa.yi.org/ is its location, we'll worry about
getting more official domains later.

Its a wiki.  Go nuts.  Err on the side of editing rather than doing
nothing.  Not sure if something should go on the wiki?  Put it there,
it can be deleted.

This is MediaWiki, the wiki which Wikipedia runs.  Its got some
features and differences from other wikis, so please read
http://perl-qa.yi.org/index.php/MediaWiki_Editing_Tips to learn how to
use it most effectively.

I've put together a short list of things you can do for the Wiki.
http://perl-qa.yi.org/index.php/What_can_I_do%3F

Those of you who have proposed TAP extensions, kindly scrape the
details off the mailing list, write them up on the wiki and list them
here:
http://perl-qa.yi.org/index.php/TAP_Proposals

Those writing TAP parsers, kindly write them up on the wiki and list them here:
http://perl-qa.yi.org/index.php/TAP_Parsers

Those writing TAP producers (things which can produce TAP output.  ie.
Test::Builder, libtap, Test.pm, Selenium?...), write them up on the
Wiki and list them here:
http://perl-qa.yi.org/index.php/TAP_Producers

Module Signatures [was Re: On "Gaming" CPANTS...]

[Jonathan Rockway]

> It adds a dependency on a binary application (gpg) that users have to
> install by hand, doesn't check for the presence of it properly, and if
> you don't have it, installs an enormous chain of dependencies, with said
> deps having some major issues of their own.
>
> It's become bad enough that Module::Signature is being pulled from
> Bundle::CPAN and being disabled by default in CPAN.pm, until
> Module::Signature gets a maintainer capable that can make it somewhat
> saner.

I think the solution (to dependency hell) is to dictate that CPAN
modules be signed with a standard algorithm.  OpenPGP allows too many
different algorithms, hence the 22 modules Crypt::OpenPGP is dependent
on.  The only strong reason to stick with OpenPGP is that it has the
whole web-of-trust and keyserver infrastructure.

If we can live without that, then I could write a small "cpansign"
script that just uses Crypt::DSA to sign the distribution, and then have
Module::Signature just verify that DSA signature.  There's still a
dependency issue, but 21 fewer of 'em.  DSA can be made to be portable
if it isn't already.  (RSA is fine too, then I could sign my modules
with my OpenPGP smartcard ;)

If we adopted this scheme, maybe we could just have authors upload their
keys to PAUSE (or some other "Trusted Source"), and have people that
want to verify distributions pull the keys down from there.

The disadvantage of this is that the PAUSE master could forge
distributions, as could someone performing a MITM attack on your key
download.

However, this could all happen anyway.  I have a few keys of CPAN
authors in my keyring, but I've never verified the fingerprints in real
life... so for all I know, someone could be tampering with my
distributions as we speak.  This message might not really be from Jon
Rockway :)

On a related note, I sent some patches in to the Crypt::OpenPGP author a
while ago but never heard anything back.  Is that module still being
maintained?

Regards,
Jonathan Rockway



signature.asc
Description: OpenPGP digital signature

Re: Volunteer wanted: We need a new wiki.

[David Golden]

Randy W. Sims wrote:
I don't know much about SocialText. Is there a converter, so that if you 
put something up temporarily in MediaWiki, it can later be converted and 
moved to SocialText?


I know there are a whole series of HTML::WikiConverter dialects on CPAN. 
 I haven't used it, but it seems like it has the right idea.  If there 
isn't a SocialText dialect plugin already, I'm sure someone could whip 
one up.


Regards,
David

CPAN and META.yml: no_index dir vs directory

[David Golden]

To the Illuminated Masters of CPAN and META.yml:

Apparently, my upload of Perl::Dist::Vanilla spuriously indexed 
directories that I thought I had listed as "no_index".


On examination, it appears that the META.yml spec says to use a "dir" 
entry under "no_index" whereas PAUSE/CPAN/search.cpan.org appears to 
honor "directory" (based on the META.yml I see for perl-5.8.8).  Compare 
to the spec:


http://module-build.sourceforge.net/META-spec-v1.2.html#no_index

I hereby appeal to the Powers That Be (tm) to resolve this inconsistency 
for the clarity and benefit of us all.  :-)


Some potential options:

(a) Add "directory" as a synonym to the spec and add "dir" as something 
that CPAN sites recognize.


(b) Change the spec to "directory" -- if CPAN sites are the only real 
user of META.yml no_index, then the pain should be minimal.


(c) Change CPAN sites to follow the spec, despite breaking many 
distributions' current indexing.


Of these three, I'd suggest (a) or (b).  (a) seems crufty but breaks 
nothing.  (b) is conceptually cleaner but might break a few things.  (c) 
seems like a nightmare.


Regardless, I encourage PAUSE admins to better document how CPAN uses 
no_index (as it currently points to a missing spec file, no less).


Thank you all very much,

Regards,
David Golden

Re: Volunteer wanted: We need a new wiki.

[Randy W. Sims]

Michael G Schwern wrote:

On 7/5/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote:

The thing about using MediaWiki is that it's not written in Perl.  Not
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of
negative message when Perl QA doesn't use a Perl-based Wiki?


Do I worry that qa.perl.org is running Apache?  That's not written in Perl.
I'm sending mail via GMail, you're using Thunderbird.  Not Perl.
This mailing list is run with ezmlm on qmail.  They're not written in Perl.

What message are we sending using all this non-Perl software?  That we
use the best tool for the job, not the one with the best political
connections.  That we're focused on QA and not in the business of
maintaining MTAs, MUAs, web servers, mailing lists or wikis.

If it bothers you that we're not using a Perl-based wiki, improve the
Perl wikis.  Or think less provincially, its ok to use more than one
language.  Or don't let it bother you.

Honestly, it could be written in COBOL for all I care.  Its well
written, it works well and, thanks to Tyler MacDonald, it works now.



Thank you for those sensible words. This type discussion happens way too 
often.


There have been several threads lately on wikis. The perl6-user group 
had a long one; and someone has even offered a bounty for a perl 6 based 
wiki. Meanwhile they have set up on . 
The maintainers of that site, Australia and New Zealand PM, have made it 
available to other perl projects as well.


A request for a decent central perl wiki was also requested on the 
advocacy list where perl.net.au was again mentioned and made available, 
and Ask mentioned setting a SocialText based wiki for perl:



When Socialtext releases their beta I'm planning to play with it and likely 
setup an instance for the perl community (FWIW).


I don't know much about SocialText. Is there a converter, so that if you 
put something up temporarily in MediaWiki, it can later be converted and 
moved to SocialText?


Randy.

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

[Adam Kennedy]

Define "some" please :)


Ricardo has said he is, for example.


And, "improve compatibility" - with broken systems? OMG. :)

You mean we now don't sign packages anymore just because someone isn't 
able to check the signature? 

The right way is to tell the user to fix their borken system, not to  
remove features.


The concept of user being capable of doing ANYTHING is invalid in 
toolchainland. The user isn't able to, and shouldn't have to, do anything.


Module::Signature is broken, in several ways, on many platforms.

It adds a dependency on a binary application (gpg) that users have to 
install by hand, doesn't check for the presence of it properly, and if 
you don't have it, installs an enormous chain of dependencies, with said 
deps having some major issues of their own.


It's become bad enough that Module::Signature is being pulled from 
Bundle::CPAN and being disabled by default in CPAN.pm, until 
Module::Signature gets a maintainer capable that can make it somewhat saner.


CPAN.pm has to work everywhere, and currently Module::Signature is 
breaking that. So it's getting shelved until it works.


Adam K

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Andy Lester]

On Jul 5, 2006, at 5:26 PM, chromatic wrote:


If you
cannot or will not work with the community, don't be surprised when  
the

community has little interest in working with you.


Please also LISTEN to what we're saying.  A thread w/Shlomi typically  
has responses from Shlomi that rebut the concerns of others, rather  
than assimilating them.


The other thing to remember, Shlomi, is that Test::Run is entirely  
for Shlomi.  Nobody is asking for it.  The market for Test::Run does  
not exist.


It's fine to write software to scratch an itch.  Just don't be  
surprised when your itch is unique to you.


xoa

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Volunteer wanted: We need a new wiki.

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> >> You win!  Set it up.  Let us know when its online.  We'll worry about
> >> getting a proper domain/uri for it later.
> >
> >Done! http://qa.yi.org/
> 
> Thanks!
> 
> Could you switch that to perl-qa.yi.org?  Just to make it clear this
> isn't yi.org's QA department.

yi.org's QA department... I almost snorted me tea out of my nose when I read
that. ;-)

OK, I've set perl-qa.yi.org to point there. I figured once it was ready for
production you'd point a more official perly URL at it. (If/when you
want to do that, please let me know so I can update apache etc...)

Cheers,
Tyler

Re: Volunteer wanted: We need a new wiki.

[Michael G Schwern]

On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> >I'd be happy to. yi.org is already running a few mediawikis, as well as
> >cpants.perl.org. Let me know and I'll get it set up.
>
> You win!  Set it up.  Let us know when its online.  We'll worry about
> getting a proper domain/uri for it later.

Done! http://qa.yi.org/


Thanks!

Could you switch that to perl-qa.yi.org?  Just to make it clear this
isn't yi.org's QA department.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[chromatic]

On Wednesday 05 July 2006 15:02, Shlomi Fish wrote:

> Test::Run is licence-compatible with the core.

I do not think those words mean what you think they mean.

> Some of Test::Run is 
> licensed under the GPL and Artistic (version 1.0) licence which is the
> licence of the perl 5 core. The other part is licensed under the MIT X11
> license which can be freely linked against each one and can also be
> converted to the Perl dual-license by anyone who re-distributes the code.

Hypothetically speaking, if Test::Run gets in the core as a dual-lived module 
and maintains its current licensing, if I were to write a patch against it 
and submit it to p5p, would I have to license the patch as 
Artistic/GPL/BSD/MIT to match all of the licenses on the code?  (Is it even 
*possible* to link all of those licenses together without the GPL trumping at 
least the latter two?)  What if I use the standard Perl license?  That part 
can go in the core, but it's more restrictive than your preferred license, so 
you can't use it.

You're a smart guy and you have a lot to contribute, but there's a reason 
people complain when you wander so far away from the community and start 
doing things on your own: it's a real hassle for the rest of us.  If you 
cannot or will not work with the community, don't be surprised when the 
community has little interest in working with you.

(Please don't argue about how this is not a problem in theory.  We're not 
working in theory here.  We're working in practice, and in practice I have a 
Really Big Problem here that no amount of theoretical handwaving can 
dismiss.)

-- c

Re: Volunteer wanted: We need a new wiki.

[Michael G Schwern]

On 7/5/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote:

The thing about using MediaWiki is that it's not written in Perl.  Not
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of
negative message when Perl QA doesn't use a Perl-based Wiki?


Do I worry that qa.perl.org is running Apache?  That's not written in Perl.
I'm sending mail via GMail, you're using Thunderbird.  Not Perl.
This mailing list is run with ezmlm on qmail.  They're not written in Perl.

What message are we sending using all this non-Perl software?  That we
use the best tool for the job, not the one with the best political
connections.  That we're focused on QA and not in the business of
maintaining MTAs, MUAs, web servers, mailing lists or wikis.

If it bothers you that we're not using a Perl-based wiki, improve the
Perl wikis.  Or think less provincially, its ok to use more than one
language.  Or don't let it bother you.

Honestly, it could be written in COBOL for all I care.  Its well
written, it works well and, thanks to Tyler MacDonald, it works now.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Shlomi Fish]

On Wednesday 05 July 2006 23:55, chromatic wrote:
> On Wednesday 05 July 2006 12:28, Shlomi Fish wrote:
> > I'd like to suggest a generic proposal for the Perl Foundation Grants.
> > Note that I'm not going to take it myself, because I just started a new
> > job and would like to commit to it. However, I can be the mentor for this
> > grant. I'm posting it here to get some reactions before I put it in my
> > use.perl.org journal, etc.
>
> You want TPF to pay some unspecifed and unidentified other person 

Not exactly. I suggested that if anyone is interested in working on Test::Run, 
he can file a proposal for a grant saying he'd like to work on it with me as  
a mentor. I still don't have anyone who can work on it. This is similar to 
Adam Kennedy's "Strawberry Perl" developer wanted:

http://use.perl.org/~Alias/journal/29174

Albeit mine was possibly too badly phrased.

> to 
> continue a fork of a core module that can't ever replace the core module
> because of its licensing?
>

Test::Run has no licensing problems. Some parts of it are under the Perl 
dual-license. The other parts are under the MIT X11 license. One can easily 
re-license MIT X11-licensed code under any other licence.

Sheez...

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Shlomi Fish]

On Wednesday 05 July 2006 23:51, Ricardo SIGNES wrote:
> * Shlomi Fish <[EMAIL PROTECTED]> [2006-07-05T15:28:28]
>
> > The grant is about Test::Run, which is a fork of Test::Harness that aims
> > to greatly refactor and modularise it. I've already revamped and
> > re-written a lot of code for it, but there's still a lot that needs to be
> > done.
>
> [...]
>
> > Some of the code in Test::Run is derived from the code of Test::Harness,
> > which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However,
> > some code was written from scratch and due to my personal preferences, it
> > was licensed under the MIT X11 Licence[1]. I prefer that all new code
> > will be also MIT X11 licence, and that existing code will retain its
> > original licensing terms.
>
> [...]
>
> > TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and
> > others.
>
> So, you want to have someone (other than you) work on a project that
> largely seems to duplicate the functionality of existing code.  Among the
> existing code whose functionality is being duplicate is code still under
> development.

Let me try and understand what you mean and explain what I want. Test::Run was 
started before TAP::Harness in the aim to transform Test::Harness into 
something more modular. A large part of this goal was already acheived, see 
what exists now at:

http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/

Among the tasks that were achieved so far in Test::Run are:

1. More tests were added.

2. An almost complete Object-Oriented interface instead of a procedural 
interface.

3. Many long functions were broken into smaller one.

4. All the command line and %ENV handling was moved into a separate module.

5. A plugin interface was defined and several plugins were written.

But like I said there is still a lot of work to be done.

Now TAP::Harness was started several months after the first release of 
Test::Run. Its aim is to provide another implementation for processing TAP, 
which from what I understood will share much of the goals.

>
> The other project is being done with no TPF funding and will be capable of
> becoming part of the core in future Perls, largely superseding the existing
> test framework.

So hopefully will Test::Run. Except that now that I have a full-time job, it 
would be nice if someone can work on it as well as me.

>
> You want funding for a parallel project that will be not be
> license-compatible with the core.

Test::Run is licence-compatible with the core. Some of Test::Run is licensed 
under the GPL and Artistic (version 1.0) licence which is the licence of the 
perl 5 core. The other part is licensed under the MIT X11 license which can 
be freely linked against each one and can also be converted to the Perl 
dual-license by anyone who re-distributes the code.

And like I said, I don't want the funding for me - I want it for someone who 
volunteers to work on the project.

>
> I don't see how this would be worth TPF's money.  It might be a very useful
> project for people who use the code or for people who want to steal ideas,
> but I don't see how it fills a really critical void in the language or its
> toolset.

Please read my answers above and also re-read my original draft of the 
proposal.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Volunteer wanted: We need a new wiki.

[Jonathan T. Rockway]

I'd prefer MediaWiki (that which
Wikipedia uses).


I'm working on making Socialtext open source right now.  I plan to  
put up a wiki based on it very soon.


This sounds like the best idea.

The thing about using MediaWiki is that it's not written in Perl.  Not 
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of 
negative message when Perl QA doesn't use a Perl-based Wiki?  I know 
Rails gets criticized for running their site on PHP... you'd think 
they'd just rename it to index.rhtml or whatever :)


Regards,
Jonathan Rockway

Re: Volunteer wanted: We need a new wiki.

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> >I'd be happy to. yi.org is already running a few mediawikis, as well as
> >cpants.perl.org. Let me know and I'll get it set up.
> 
> You win!  Set it up.  Let us know when its online.  We'll worry about
> getting a proper domain/uri for it later.

Done! http://qa.yi.org/

- Tyler

Re: Proposal Suggestion - Test::Run

[Jonathan T. Rockway]

Two comments, pretty much agreeing with chromatic and Ricardo:

1)  How would this proposed module benefit the perl community?  Why 
can't you fix things in Test::Harness and send the patch in?  If you fix 
deployed modules, everyone wins.  If you write your own module, it sits 
on CPAN unused.


What exactly is wrong with Test::Harness, anyway?  The development team 
is pretty agreeable, the code is good, the module works, etc.  Is there 
some large problem I'm missing?  (A problem so large that TPF needs to 
*pay* someone to fix it!?)


2) If you use GPL'd code in an MIT-licensed app, the entire app becomes 
GPL.  I don't think you can say, "this requires xyz GPL'd code, but if 
it didn't it would be MIT".  It's GPL by virtue of requiring GPL code.  
(Hence the accusation that the GPL is 'viral' or whatever.)  IANAL, but 
this is my understanding from reading the license, the FSF's site, etc.  
If the code isn't derived, though, feel free to MIT license it.  (The 
fact of the matter, though, is that Perl uses the Perl license.  I don't 
really love the Artistic license, but I release my perl code under the 
dual license because Everyone Else Does.  It makes everything work 
nicely and builds community too  :)


Just my two cents :)

Regards,
Jonathan Rockway

Shlomi Fish wrote:


Hi all!

I'd like to suggest a generic proposal for the Perl Foundation Grants. Note 
that I'm not going to take it myself, because I just started a new job and 
would like to commit to it. However, I can be the mentor for this grant. I'm 
posting it here to get some reactions before I put it in my use.perl.org 
journal, etc.


The grant is about Test::Run, which is a fork of Test::Harness that aims to 
greatly refactor and modularise it. I've already revamped and re-written a 
lot of code for it, but there's still a lot that needs to be done.


Here are some Test::Run links:

1. Lightning Talk about Test::Run - 
http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/


2. use.perl.org journal entries:
http://use.perl.org/~Shlomi+Fish/journal/27467
http://use.perl.org/~Shlomi+Fish/journal/27887

(they contain a lot of links).

---

Licencing Issues:
=

Some of the code in Test::Run is derived from the code of Test::Harness, which 
is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some code 
was written from scratch and due to my personal preferences, it was licensed 
under the MIT X11 Licence[1]. I prefer that all new code will be also MIT X11 
licence, and that existing code will retain its original licensing terms.


Comparison with Similar Efforts:


* Test::Harness is the old harness module of Perl 5, from which Test::Run was 
derived. It is not very Object Oriented, suffers from some modularity issues, 
and is generally hard to properly adapt. Often, customisations to it need to 
be kept and maintained in house.


Test::Run is no longer backwards compatible with Test::Harness. The internal 
and external interface was changed.


* TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. 
It has similar goals to Test::Run, but has a different methodology of trying 
to achieve it. 

* TAP::Parser by Ovid is a work-in-progress module that aims to be a modular 
event-based parser for TAP output. Test::Run may eventually convert to use it 
instead of its current ad-hoc TAP handling routine (that was inherited from 
Test::Harness).


Orthogonal to all of these are the various Perl and non-Perl TAP generators 
such as Test::Builder, Test::Simple, Test::More, Test::Base, and the 
http://search.cpan.org/~petdance/Test-Harness-2.62/lib/Test/Harness/TAP.pod#Non-Perl_TAP
. Test::Run and friends are not concerned by them as long as the script that 
performs the tests' generates correct TAP.


Scope of the Project:
=

This project aims to do the following:

1. Finish refactoring Test::Run::Obj, Test::Run::Straps and the other modules 
derived from Test::Harness. One should probably have read "Refactoring" by 
Martin Fowler, for some indication on which "bad smells" exist in bad code, 
and how bad code should be methologicaly refactored if it has them. "Perl 
Best Practices" is also possibly a good read. (albeit I only began reading 
it).


2. Move some of the functionality of Test::Harness that's currently in the 
Test::Run::Obj core into plugins.


3. Update the POD documentation for the new version.

4. Extend (using plugins, etc.) for:
- Formatting the messages using templates or callbacks.
- Colours in the output. (Already exist to some extent).
- HTML, XML and YAML (and others) Output.
- Persistent Running.
- Interrupted GUI running.

Michael G. Schwern also suggested the following: (in the context of 
TAP::Harness)


<<<
Right now the use cases I have in mind include things such as
parallelized test runs, fancy GUI and HTML outputs (for example,
TAP::Model::HTMLMatrix), multiple,

Re: Volunteer wanted: We need a new wiki.

[Michael G Schwern]

On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:

I'd be happy to. yi.org is already running a few mediawikis, as well as
cpants.perl.org. Let me know and I'll get it set up.


You win!  Set it up.  Let us know when its online.  We'll worry about
getting a proper domain/uri for it later.

Re: Volunteer wanted: We need a new wiki.

[Andy Lester]

On Jul 5, 2006, at 4:17 PM, Michael G Schwern wrote:


We need a new wiki.  schwern.org is too anemic to run anything serious
(64 megs of RAM, woo!).  We need a volunteer with server space to
setup and maintain the Perl QA Wiki.  I'd prefer MediaWiki (that which
Wikipedia uses).  It seems the best known, best of breed with the
least fuss.


I'm working on making Socialtext open source right now.  I plan to  
put up a wiki based on it very soon.


If you can wait a few days, I'll have something up at rakudo.org.

xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Volunteer wanted: We need a new wiki.

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> These TAP extension proposals and designs for parsers and questions
> for details about the TAP grammar... they should all go into the Wiki.
> But the Perl QA Wiki sucks.  Its slow.  Its spammed.  UseModWiki
> sucks.  And I don't have the time to maintain it.
> 
> We need a new wiki.  schwern.org is too anemic to run anything serious
> (64 megs of RAM, woo!).  We need a volunteer with server space to
> setup and maintain the Perl QA Wiki.  I'd prefer MediaWiki (that which
> Wikipedia uses).  It seems the best known, best of breed with the
> least fuss.
> 
> Please contact me if you would like to do this.

I'd be happy to. yi.org is already running a few mediawikis, as well as
cpants.perl.org. Let me know and I'll get it set up.

Cheers,
Tyler

Volunteer wanted: We need a new wiki.

[Michael G Schwern]

These TAP extension proposals and designs for parsers and questions
for details about the TAP grammar... they should all go into the Wiki.
But the Perl QA Wiki sucks.  Its slow.  Its spammed.  UseModWiki
sucks.  And I don't have the time to maintain it.

We need a new wiki.  schwern.org is too anemic to run anything serious
(64 megs of RAM, woo!).  We need a volunteer with server space to
setup and maintain the Perl QA Wiki.  I'd prefer MediaWiki (that which
Wikipedia uses).  It seems the best known, best of breed with the
least fuss.

Please contact me if you would like to do this.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[chromatic]

On Wednesday 05 July 2006 14:04, Andy Lester wrote:

> On Jul 5, 2006, at 3:55 PM, chromatic wrote:

> > You want TPF to pay some unspecifed and unidentified other person
> > to continue a fork of a core module that can't ever replace the core
> > module because of its licensing?

> But at least he'll act as mentor.

I have no involvement with TPF leadership, but I'm not sure TPF is in the 
business of funding examples of how not to do F/LOSS development.

-- c

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Andy Lester]

On Jul 5, 2006, at 3:55 PM, chromatic wrote:

You want TPF to pay some unspecifed and unidentified other person  
to continue
a fork of a core module that can't ever replace the core module  
because of

its licensing?


But at least he'll act as mentor.

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[chromatic]

On Wednesday 05 July 2006 12:28, Shlomi Fish wrote:

> I'd like to suggest a generic proposal for the Perl Foundation Grants. Note
> that I'm not going to take it myself, because I just started a new job and
> would like to commit to it. However, I can be the mentor for this grant.
> I'm posting it here to get some reactions before I put it in my
> use.perl.org journal, etc.

You want TPF to pay some unspecifed and unidentified other person to continue 
a fork of a core module that can't ever replace the core module because of 
its licensing?

-- c

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Ricardo SIGNES]

* Shlomi Fish <[EMAIL PROTECTED]> [2006-07-05T15:28:28]
> The grant is about Test::Run, which is a fork of Test::Harness that aims to 
> greatly refactor and modularise it. I've already revamped and re-written a 
> lot of code for it, but there's still a lot that needs to be done.

[...]
 
> Some of the code in Test::Run is derived from the code of Test::Harness,
> which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some
> code was written from scratch and due to my personal preferences, it was
> licensed under the MIT X11 Licence[1]. I prefer that all new code will be
> also MIT X11 licence, and that existing code will retain its original
> licensing terms.

[...]

> TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. 

So, you want to have someone (other than you) work on a project that largely
seems to duplicate the functionality of existing code.  Among the existing code
whose functionality is being duplicate is code still under development.

The other project is being done with no TPF funding and will be capable of
becoming part of the core in future Perls, largely superseding the existing
test framework.

You want funding for a parallel project that will be not be license-compatible
with the core.

I don't see how this would be worth TPF's money.  It might be a very useful
project for people who use the code or for people who want to steal ideas, but
I don't see how it fills a really critical void in the language or its toolset.

-- 
rjbs


signature.asc
Description: Digital signature

Re: TAP Grammar

[Chris Dolan]

On Jul 3, 2006, at 6:33 PM, chromatic wrote:


On Monday 03 July 2006 09:01, Jonathan T. Rockway wrote:


That said, I would be interested.  I'm still trying to page all the
perl6/parrot grammars (PGE, TGE, etc.) into my brain, so any  
additional

examples would helpful, interesting, and fun.  For me, anyway :)


Jerry Gay just wrote a PGE TAP grammar:



-- c


I hacked a rudimentary test case for that grammar, borrowing heavily  
from Punie:

  https://svn.clotho.com/public/parrot-experiments/TAP/

To run it, edit the first line of the Makefile to specify the path to  
PARROT_DIR and run "make".  My tests found a few bugs in Jerry's  
grammar.  My fixed version of that grammar is here:

  https://svn.clotho.com/public/parrot-experiments/TAP/grammars/TAP.pg

Chris

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Shlomi Fish]

Hi all!

I'd like to suggest a generic proposal for the Perl Foundation Grants. Note 
that I'm not going to take it myself, because I just started a new job and 
would like to commit to it. However, I can be the mentor for this grant. I'm 
posting it here to get some reactions before I put it in my use.perl.org 
journal, etc.

The grant is about Test::Run, which is a fork of Test::Harness that aims to 
greatly refactor and modularise it. I've already revamped and re-written a 
lot of code for it, but there's still a lot that needs to be done.

Here are some Test::Run links:

1. Lightning Talk about Test::Run - 
http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/

2. use.perl.org journal entries:
http://use.perl.org/~Shlomi+Fish/journal/27467
http://use.perl.org/~Shlomi+Fish/journal/27887

(they contain a lot of links).

---

Licencing Issues:
=

Some of the code in Test::Run is derived from the code of Test::Harness, which 
is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some code 
was written from scratch and due to my personal preferences, it was licensed 
under the MIT X11 Licence[1]. I prefer that all new code will be also MIT X11 
licence, and that existing code will retain its original licensing terms.

Comparison with Similar Efforts:


* Test::Harness is the old harness module of Perl 5, from which Test::Run was 
derived. It is not very Object Oriented, suffers from some modularity issues, 
and is generally hard to properly adapt. Often, customisations to it need to 
be kept and maintained in house.

Test::Run is no longer backwards compatible with Test::Harness. The internal 
and external interface was changed.

* TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. 
It has similar goals to Test::Run, but has a different methodology of trying 
to achieve it. 

* TAP::Parser by Ovid is a work-in-progress module that aims to be a modular 
event-based parser for TAP output. Test::Run may eventually convert to use it 
instead of its current ad-hoc TAP handling routine (that was inherited from 
Test::Harness).

Orthogonal to all of these are the various Perl and non-Perl TAP generators 
such as Test::Builder, Test::Simple, Test::More, Test::Base, and the 
http://search.cpan.org/~petdance/Test-Harness-2.62/lib/Test/Harness/TAP.pod#Non-Perl_TAP
. Test::Run and friends are not concerned by them as long as the script that 
performs the tests' generates correct TAP.

Scope of the Project:
=

This project aims to do the following:

1. Finish refactoring Test::Run::Obj, Test::Run::Straps and the other modules 
derived from Test::Harness. One should probably have read "Refactoring" by 
Martin Fowler, for some indication on which "bad smells" exist in bad code, 
and how bad code should be methologicaly refactored if it has them. "Perl 
Best Practices" is also possibly a good read. (albeit I only began reading 
it).

2. Move some of the functionality of Test::Harness that's currently in the 
Test::Run::Obj core into plugins.

3. Update the POD documentation for the new version.

4. Extend (using plugins, etc.) for:
- Formatting the messages using templates or callbacks.
- Colours in the output. (Already exist to some extent).
- HTML, XML and YAML (and others) Output.
- Persistent Running.
- Interrupted GUI running.

Michael G. Schwern also suggested the following: (in the context of 
TAP::Harness)

<<<
Right now the use cases I have in mind include things such as
parallelized test runs, fancy GUI and HTML outputs (for example,
TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a
URL and get the TAP from that; run HTML through a validator which
produces TAP; run a C program which spits out TAP), "enhanced" TAP
output (ex. colors; levels of verbosity), and the ability to smoothly
handle TAP extensions.
>>>

Roles in the Project:
=

Like I said I'm going to be the mentor for the project, not the one who 
actually performs it. The one who takes it will receive most (or all) of the 
money of the grant while doing most of the work on Test::Run.

I will aid the project proposer by giving him a Berlios.de developer status 
for the Test-Run project (with Subversion commit access) and also eventually 
make him a CPAN co-maintainer for the appropriate namespaces, so he can 
upload modules there.

One note is that so far I did most of the work on Test::Run, and so no-one 
else has much first-hand experience with it. However, I believe any prior 
experience with the Test::Harness code or even with Perl 5 testing in general 
will do, and I'll be glad to help any newcomer feel comfortable with the 
code.

I can be reached in the following means:

http://www.shlomifish.org/me/contact-me/

Regards,

Shlomi Fish

[1] - The MIT X11 Licence ( http://en.wikipedia.org/wiki/MIT_License )  a 
BSD-style licence that is almost ent

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

[Tels]

Moin,

On Wednesday 05 July 2006 17:56, David Golden wrote:
> Randy J. Ray wrote:
> > I'm a fairly-recent addition to the list. I've read a good part of
> > the
>
> Welcome!
>
> > Secondly, having recently added digital-signing to a few of my
> > modules, perhaps the presence of a SIGNATURE file might be a Kwalitee
> > marker (with the caveat that it should be an actual
> > Module::Signature-generate artifact, not just a zero-length file
> > named "SIGNATURE"). I found the steps needed to add this to be pretty
> > simple, not much more work than adding POD and POD-coverage tests to
> > those same modules.
>
> Module::Signature has caused a problem at various points for people who
> have it installed, but not configured properly.  Given that, some
> developers have started removing SIGNATURE to improve compatibility.

Define "some" please :)

And, "improve compatibility" - with broken systems? OMG. :)

You mean we now don't sign packages anymore just because someone isn't 
able to check the signature? 

The right way is to tell the user to fix their borken system, not to  
remove features.

> Given that Mod::Sig checks are just that the signature is valid, not
> that the signature matches a known/registered developer, the security
> aspect is already minimal.

This is a security bug and should then be fixed ASAP.

But AFAIK, PAUSE checks the key upon upload, and I am *think* it would 
also check that the maintainer who uploads the package is the one who 
signed it. Anything else would be a stupid lapse and I can't imagine 
Andreas would be that stupid :)

Best wishes,

Tels

-- 
 Signed on Wed Jul  5 19:53:45 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Most of the screen on a blog is blank for an imaginary populace of
 readers still using 640x480 resolution. I didn't buy a 19" monitor to
 have 50% of its screen realestate pissed away on firing white pixels,
 you assholes." -- maddox from xmission



pgpm5ers7dFNG.pgp
Description: PGP signature

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

[David Golden]

Randy J. Ray wrote:

I'm a fairly-recent addition to the list. I've read a good part of the


Welcome!


Secondly, having recently added digital-signing to a few of my modules,
perhaps the presence of a SIGNATURE file might be a Kwalitee marker (with
the caveat that it should be an actual Module::Signature-generate artifact,
not just a zero-length file named "SIGNATURE"). I found the steps needed to
add this to be pretty simple, not much more work than adding POD and
POD-coverage tests to those same modules.


Module::Signature has caused a problem at various points for people who 
have it installed, but not configured properly.  Given that, some 
developers have started removing SIGNATURE to improve compatibility.


Given that Mod::Sig checks are just that the signature is valid, not 
that the signature matches a known/registered developer, the security 
aspect is already minimal.


Regards,
David Golden

Re: TAP::Harness

[Geoffrey Young]

Geoffrey Young wrote:
> I've mentioned the idea of making it simple to use
> plan() and Test::More functions before

blarg... insert "separately" ^ here.  all the rest is pretty simple
already :)

--Geoff

Re: TAP::Harness

[Geoffrey Young]

sorry for dropping in on this late, but it was a holiday weekend :)

> * How can I help?
> 
> Provide use cases, what would you want to do with Test::Harness if you
> could?  What are you doing with Straps?  What features do other
> testing systems (JUnit, for example) have that you'd like to see in
> Perl?

the current threads are a bit to wade through, but in case nobody else
has brought it up, I've mentioned the idea of making it simple to use
plan() and Test::More functions before[1], because it's what we do over
in httpd land (plan in perl from the shell, emit TAP in perl from the
server).  you can do it now[2] but ideally it should be a bit more
seamless I'd think.

since you're asking :)

--Geoff

[1] http://www.nntp.perl.org/group/perl.qa/5445
[2] http://www.nntp.perl.org/group/perl.qa/5455