Re: Tidying up CPAN author directories
Neil, Thank you for notifying me. Just took option 1 and confirmed the result via PAUSE. DANKOGAI > On Jul 8, 2016, at 02:25, Neil Bowers wrote: > > Hi Kogai-san, > > I’m one of the PAUSE admins. The NOC have let us know that we’re getting low > on diskspace on the CPAN master. This is caused by old (superseded) releases > being retained in CPAN author directories. So we’ve identified the authors > who can free up the most diskspace by deleting old releases from their author > directory. > > Deleting the old releases of your Encode distribution would free up about > 140M, plus you have old releases of your other distributions (such as > Unicode-Unihan and Encode-JIS2K) as well. > > Would you be happy to cull your old releases from your CPAN author directory > please? All releases you’ve ever done will always be available from your > BackPAN author directory: > http://backpan.perl.org/authors/id/D/DA/DANKOGAI/ > > There are at least 3 ways we can make this happen: > > 1. you could use the script here: > https://gist.github.com/xdg/1739bea8ef36c4a48e4d2969bc31bf38 > 2. you can manually mark files for deletion via the PAUSE interface > 3. you can give me permission to do this on your behalf > > The script mentioned in (1) was written by David Golden and Rik Signes. It > keeps all developer releases later than a stable release, keeps up to 3 > stable releases, and deletes everything else. Use at your own risk, of course. > > If you give me permission, I would delete everything other than the latest > release for anything older than a year, and 3 releases of anything less than > a year old. When marked for deletion, you’d have 3 days to check and revert > anything you’re not happy with, before PAUSE would actually delete them. > > Thanks for your help — please ask if anything isn’t clear, or if you want to > suggest something else. > > Cheers, > Neil >
Re: Namespace [Was: Re: MacOSX::File]
Chris, Sorry for not responding. On 2002.01.11, at 08:37, Chris Nandor wrote: >> Anyway, since then my policy to upload a module is as follow; >> >> 0) Make sure it does not exist yet. >> 1) Upload and see what happens. > > Well, I am a member of the [EMAIL PROTECTED] cabal; the general practice > is that if something is OK, we don't necessarily respond. If no one > responds after a week or so, you're probably fine. But that doesn't > mean you shouldn't ask first. I don't necessarily think that your name > is wrong, but I do think you should post to [EMAIL PROTECTED] first for > such things as new top-level namespaces. Maybe Mac::X would be better, > I dunno. That's why it is discussed first. :) Okay, I will. I heareby request namespace MacOSX for the use by modules that are platform-specific to MacOS X. As for the replies (or lack there of) from [EMAIL PROTECTED], 0 reply for OK is pretty much like Unix commands. But for administrative this is terribly wrong. Simple autorespond like that of CPAN would be welcome. As for the namespace Mac::X, I object because this is confusing with X window. > My problem is that I think this module should have the same interface as > Mac::Files and should be called Mac::Files and then programmers on both > platforms can "use Mac::Files" and just have it work. Mine does not have the same interface. That's why I picked the different name space to begin with. After XS (therefore C compiler) is imperative for make install MacOSX::File (though binary distribution is considered when it gets stable) something you can't expect of MacOS 9 and below. Oh, that reminds me. Is there a canonical way to upload BINARY version of the module? I can make it so that Makefile.PL works like an installer rather than Makefile generator but is it the way? > Well, OK, maybe not. But I do want *A* module called "Mac::Files" on > Mac OS X that has the same interface as Mac::Files on Mac OS, though, > and what I don't want is for there to be confusion in the long run as to > what these modules should and shouldn't do ... It would be nice, too but that requires more than my share of work. Resorting to reinventing a wheel is a pain enough. > What I really should do is just port the Mac:: modules, but I don't have > the time to do that work. :/ Yes, that's always the problem. As for MacOSX::File, I was too lazy to use Finder to backup a hundred of thousand of files (vanilla MacOS X with Developer Kit well exceeds 100,000 files). I was too impatient to wait for someone come of a module like this. And I was too hubristic to wait for the verdict of [EMAIL PROTECTED] What other virtues do I need :) Dan the Man with Too Many Namespaces to Browse
Re: Namespace [Was: Re: MacOSX::File]
On 2002.01.15, at 02:05, Chris Devers wrote: >>> Yes, I agree it is confusing. I am not crazy about MacOSX, >>> but can think of nothing better, so I am not objecting. >> >> I have a feeling that "MacOSX" is not future-proofed. > > That's true, but it might work in the same way that "Win32" does. There, > of course, is no Windows 32 product, but rather a family of them that > can > be described as Win32. Mac OS X is clearly a big break with what > preceded > it, and presumably Mac OS XI (or whatever it will be) will evolve from > what we have now, rather than be another fundamental break. For lack > of a > better generic name for this new family of Mac systems, MacOSX might > have > to do -- though I'd be interested in better suggestions. Aqua? Darwin? FYI Here is the reason why I picked MacOSX:: RELUCTANTLY. Mac:: should work on both world but mine does not. Aqua:: is the Name of UI so it should belong to modules that does things like Tk:: or Qt::. The biggest contender was Darwin:: but BSD world of MacOS X is the prime example that's wrong. If Darwin:: were appropriate, native /bin/ commands would have treated resource fork like MacOS. Oh well Dan the Man with Too Many Acronyms to Grok
