Re: Renaming the "QA Hackathon"?
On Tue, Apr 19, 2016 at 12:33:31PM +0200, Salve J Nilsen wrote: > > I'm looking forward to hear where this discussion goes, and where the 10th > anniversiary will be next year. (On that note, would you guys be interested > in seeing a QAH in Oslo again?) For the record, I've been thinking about proposing to hold it in Lyon again in 2017. I look forward to seeing the summary of all the feedback Neil has been gathering from the participants, as I'm quite certain it will give the next organisers many useful clue for organising a very successful event. -- Philippe Bruhat (BooK) To flaunt your strength is to make it your weakness. (Moral from Groo The Wanderer #25 (Epic))
Re: Thoughts on Kik and NPM and implications for CPAN
On Thu, Mar 24, 2016 at 05:38:13PM -0400, Olaf Alders wrote: > > > On Mar 24, 2016, at 5:02 PM, Neil Bowers <neil.bow...@cogendo.com> wrote: > > > >>> PAUSE doesn’t (currently) know the river position, but if it published > >>> a feed of deletion-schedulings, then some third-party agent could > >>> monitor the feed and check for dists that are on river. I think those > >>> are the dists that should be alerted to modules@ […] Obviously the > >>> issue here is DarkPAN: a dist might not have any CPAN dependents, but > >>> may be used plenty out in the big bad world. That’s a separate problem > >>> :-) > >> > >> I don’t think so. Plack::Middleware::Rewrite is used by a ton of people > >> and klaxons certainly ought to ring if I ever opened up that namespace. > >> The number of on-CPAN dependents is just 3 though. > > > > The key word in what I said was *any*. I think even 3 dependents should > > klaxon. > > Plus having any favourites on CPAN should also prompt the klaxon as well: I > > use favourites as a proxy for “has dependents” in both the adoption list > > and weighting dists for the PRC, and it seems to work. > > > > I still think we need a service where you can say “I’m using this dist”. I > > think I’ll add that feature to the dashboard, which I’ll be working on at > > the QAH. > > This would be pretty easy to bolt onto MetaCPAN. I was already considering > something like this to run parallel to ++ where ++ means "I recommend this" > and there's some alternate symbol for saying "I use this". This would make > it easy to have a script that would scan deps in apps and add them to your "I > use this" list in MetaCPAN. Years ago, Léon Brocard (I think) published a script that did basically explore your disk looking for use lines, and reported them for publication on some dash/leaderboard. A button for manual addition is a good first step, but something automated might give more thorough results. OK, I did a bit of search on use.perl.org, and I found these: - http://use.perl.org/use.perl.org/_acme/journal/10432.html - http://use.perl.org/use.perl.org/_acme/journal/10623.html The service is down, but the Internet Archive has some old copies: https://web.archive.org/web/20041010044220/http://www.astray.com/cpanstats/ > Then, if you're planning on making a controversial change to module Y, > you have a list of users whom you can warn or poll for advice. Preventing anonymous posts would also prevent some popularity contest and ballot stuffing. -- Philippe Bruhat (BooK) Just because you do not see it does not mean it is not there. (Moral from Groo The Wanderer #85 (Epic))
Re: CPAN River - water quality metric
On Mon, Jan 04, 2016 at 03:47:58PM +, David Cantrell wrote: > On Wed, Dec 23, 2015 at 03:46:48PM +0900, Kenichi Ishigaki wrote: > > > CPANdeps (http://deps.cpantesters.org) has been providing useful > > information on water quality. > > The main limitation to using it to judge water quality is that it only > considers the most recent version of every dependency. That is, it > samples the water quality once, ignoring the factory upstream that shits > its pants a coupla times a year. Well, it tells you if there's *currently* shit in the water. -- Philippe Bruhat (BooK) When you create a climate of peace, you have only fair weather. But where the climate is one of violence, it can only rain blood. (Moral from Groo The Wanderer #120 (Epic))
Re: Berlin Consensus document posted to toolchain-site
On Sat, May 09, 2015 at 02:38:02PM -0700, John SJ Anderson wrote: On Sat, May 9, 2015 at 10:57 AM, David Golden x...@xdg.me wrote: https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/berlin-consensus.md I've posted the Berlin Consensus document. Perhaps this will come in the color commentary version, but I wonder if there was any discussion of how to best handle the situation where a module starts way downstream but ends up way upstream because of popular adoption, *if the module author doesn't agree to the way upstream recommended policies*. The answer was fork nicely. -- Philippe Bruhat (BooK) To flaunt your strength is to make it your weakness. (Moral from Groo The Wanderer #25 (Epic))
Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD
On Thu, May 07, 2015 at 06:14:57PM +1200, Kent Fredric wrote: Even some git based workflow that published to github pages with some atrocity of jekyll would be better for this task IMHO than a wiki. ( This is also a moderately low barrier to get it working using existing contribution systems thing ) Hey, this is exactly what I was proposing in my other email: aggregating documents that live on specific branches of specific directories. I'll try to quickly produce a proof-of-concept. -- Philippe Bruhat (BooK) When you create a climate of peace, you have only fair weather. But where the climate is one of violence, it can only rain blood. (Moral from Groo The Wanderer #120 (Epic))
Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD
On Thu, May 07, 2015 at 08:33:00AM -0700, John SJ Anderson wrote: This may be a good time to point out my Jekyll-ish static site publishing framework HiD (https://metacpan.org/release/HiD) has an option to publish direct to GitHub pages. cpan.io is its own webapp, turned into a static website via my own Wallflower (https://metacpan.org/pod/wallflower). Of course, everyone has to build his own! ;-) -- Philippe Bruhat (BooK) None suffer so much in a war as those who strive to end it. (Moral from Groo The Wanderer #51 (Epic))
Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD
On Thu, May 07, 2015 at 09:30:59AM +0200, Philippe Bruhat (BooK) wrote: On Thu, May 07, 2015 at 06:14:57PM +1200, Kent Fredric wrote: Even some git based workflow that published to github pages with some atrocity of jekyll would be better for this task IMHO than a wiki. ( This is also a moderately low barrier to get it working using existing contribution systems thing ) Hey, this is exactly what I was proposing in my other email: aggregating documents that live on specific branches of specific directories. I'll try to quickly produce a proof-of-concept. It lives in the book/publishing branch: https://github.com/book/CPANio/tree/book/publishing The current reference documents are obtained from these repositories: - https://github.com/neilbowers/history-of-cpan.git - https://github.com/Perl-Toolchain-Gang/toolchain-site.git Each document has a fork me on github link pointing back to it, and so does the table of content (pointing back to the project instead of individual files). The configuration lives here: https://github.com/book/CPANio/blob/book/publishing/cpanio.yml New documents in the source repository are published automatically (see include/exclude for ways to ignore documents). Unless someone objects, I'll put this live in a day or two. -- Philippe Bruhat (BooK) Beauty may be a curse, but not as great a curse as stupidity. (Moral from Groo The Wanderer #11 (Epic))
Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD
On Thu, May 07, 2015 at 01:37:55PM +0200, Philippe Bruhat (BooK) wrote: The current reference documents are obtained from these repositories: - https://github.com/neilbowers/history-of-cpan.git Unless someone objects, I'll put this live in a day or two. Because it's much simpler to see what it looks like without having to build your local cpan.io, I've put the code live with only Neil's history of CPAN, which cpan.io was already publishing. http://cpan.io/ref/cpan/history.html The benefit is that now we're back to having a single authoritative source for that document. I've sent Neil a pull request with the patches I received for my version of the document. The only remaining commit on the book/publishing branch is the one that enables publishing the content of the toolchain-site repository. I'll only apply that if David agrees. -- Philippe Bruhat (BooK) When you wander near evil, Security is only a function of foolishness... (Moral from Groo The Wanderer #21 (Epic))
Re: How To Build A Perl Package Database
On Sat, Jan 05, 2013 at 10:33:04AM +1100, Adam Kennedy wrote: I'll say it a second time... Packlist 2.0 Take MYMETA, add an extra key with the list that will be installed, intall it in the usual place as we do now. Package manager scans the filesystem for the packlist files. Or the distribution - packlist index can be store in a well known location (top of the install directory I suppose). Might seem slow, but on SSDs scanning the filesystem like that is super super fast. -- Philippe Bruhat (BooK) When you wander near evil, Security is only a function of foolishness... (Moral from Groo The Wanderer #21 (Epic))
Re: How To Build A Perl Package Database
On Thu, Dec 20, 2012 at 05:48:10PM +0100, Johan Vromans wrote: Tim Bunce tim.bu...@pobox.com writes: A separate install database for each install location seems like the only workable approach. Store the complete distribution in a git repository? One issue I had when trying to store distributions with Git::CPAN::Hook is that if a file does not change between two versions of a distribution, then git won't detect it. That was an issue for me, as I tried to create special tree objects for each distribution, so that install this version of the distribution would basically mean apply the patch that creates the whole tree. This does not work if the tree does not contain files that haven't changed between versions. Depending on what you meant, that could be an issue for you too. -- Philippe Bruhat (BooK) When you double-cross a friend, you triple-cross yourself. (Moral from Groo The Wanderer #8 (Epic))
