First thing to clarify, I don't really envision this being turned into a CPAN module. That would be directly against its purpose.
The primary purpose here is to separate and focus development and provide a point for module authors to copy it into their project. It probably will *not* be released to CPAN and it probably will *not* be API stable. The needs of the core outweigh the needs of the few people that use it. On 2011.11.15 6:34 AM, Nicholas Clark wrote: > Other than people writing test modules, who would find it useful? Test::More is about to become a lot more complicated internally, so anyone who does things which Test::More might be using. In addition, .t files which run a bazillion tests would find it useful both for speed and memory usage. I just recommended Buddy Burden use it for some huge Data::Random tests. Abigail could use it for her enormous Regexp::Common test suites. But that's not really what it's about. The library upon which 372 core tests rely is undocumented and untested. Moving it into its own repo and tracker allows it to be tested and stable without having to go through the p5p memorial bike shed. It's a lot easier to get people to work on a single file Perl library than it is to get them to patch the Perl core. In its own project, I can hand a newbie a URL like this and say "pick one of these and do it!" https://github.com/schwern/test-more/issues?labels=Easy >> t/test.pl is very important to the Perl core tests, but it is largely >> undocumented and untested. Going through the p5p process to patch it makes >> working on it difficult and open to bike shedding. If it were dual-lived it >> could be worked on as its own thing with its own commits and tests. > > test.pl is a script, not a package. Our machinery for dealing with dual > life things is really only set up to deal with modules. So doing this is not > going to just drop in to what we have. It will exactly drop in to what we have. Pulling it into its own repository doesn't mean it has to be turned into a package and modularized and all that. It would probably become lib/test.pl and you just copy that into t/test.pl. >> By having a dedicated feed of issues and commits, careful attention could be >> paid to what code and features are going in. Close attention and discussion >> can happen about whether the code is simple enough and the features apt for >> the needs of the core. > > Surely the needs of the core *are* better determined by the core developers, > not some third party group? The groups would obviously overlap and we wouldn't be stingy with the commit bits. > Also, having upstream be anywhere other than the core actively gets in the > way of t/test.pl actually being useful to core developers (or at least to > me, as a core developer who has added things to it). We deal with dual life files all the time, the same procedure applies. If you do it a lot (and you have this year) get a commit bit. Make the changes in a sterile environment with tests. Copy it into blead. Or do it in blead and paste the commit ID into an issue on the project to get someone else to pick it up. To put this in perspective, t/test.pl was edited just 28 times this year. Nearly all of them were by you in March. > Even having it being upstream blead gets in the way of it being useful. > Right now, as all users of the core's t/test.pl are in the core, it's > possible to > > a: add things to it without stopping to think "is this a decent, supportable > API that can last forever", because if the API turns out to be wrong, > it's entirely possible to have a "flag day" commit that changes it and > all its users > b: remove things from it, because nothing is using them any more > c: not worry about what versions of perl it supports, or working round > problems in them > (Although to be fair, if a particular piece of perl syntax had been > buggy before, it's possibly something fragile that should be avoided in > case it breaks again for a different reason) > > Nothing in the above stops anyone taking a copy of test.pl and using it. > Doing this also doesn't add a layer of process into working on the core. I'm ok with all that. The goal is not API stability. Moving it to its own repo does not prevent any of a, b or c. >> If folks are cool with that, I can set up a Github repository for it. We'll >> worry about whether CPAN release is appropriate later. > > I'm distinctly uncool about doing it that way. > I'm unconvinced about doing it with blead upstream. I was thinking blead would be downstream. -- Being faith-based doesn't trump reality. -- Bruce Sterling
