Re: Renaming the "QA Hackathon"?

[Peter Rabbitson]

On 04/20/2016 09:39 PM, Aristotle Pagaltzis wrote:

* Salve J Nilsen  [2016-04-19 14:06]:

Hm "Perl Ecosystem Summit"...

I thought of that myself and ended up not proposing it because the
Annual Perl Ecosystem Summit would be the APES. But maybe that is
actually good?


Well it's on par with (or slightly better than)

Perl
Essential
Networking and
Infrastructure
Symposium

Re: Looking for prior art on conventions for dep-listing

[Peter Rabbitson]

On 03/01/2016 10:14 PM, David Golden wrote:

cpanm had --scan-deps, though it's now listed as deprecated.


I didn't phrase my question correctly. What I am after is:

Imagine you get a random checkout of some dist and/or extract a tarball. 
Aside from running `perl Makefile.PL` and visually checking what is 
missing, there is nothing semi-standard that will answer "what do I feed 
to | cpanm, so that prove -l will work".


Hope this makes more sense.

Looking for prior art on conventions for dep-listing

[Peter Rabbitson]

I am currently aware of the Module::Install-specific targets of
`make listdeps`  (only what is needed to satisfy test/runtime prereqs)
`make listalldeps`   (everything the metadata knows about)

There is the dzil alternative of:
`dzil listdeps` (everything)
`dzil listdeps --missing`   (only what is needed for test/runtime)
`dzil authordeps`	(and the kitchen sink, unclear whether --author or 
--develop or both)

`dzil authordeps --missing` (only the defective kitchen sinks)


Are there other things out there targeting the same problem-domain? Is 
there something approaching a "cross-tooling convention" ?


Cheers

Why do we keep using META.json for stuff that has nothing to do with installation

[Peter Rabbitson]

Copying a rhetorical question from #distzilla here, as it warrants a 
wider audience. The background is yet another discussion of a kludgy 
workaround where an installation with an older JSON parser is tripped by 
unicode in META.json. Unicode that doesn't really serve any purpose for 
an installing client.


 why do we continue to keep trying to stuff unicode into meta 
in the first place?
 the authorship information has nothing to do with 
installation time

 we use it for display purposes only (e.g. metacpan)
 anyone considered META.meta or similar?
 I am not even talking about 5.8 at this point - on windows 
having unicode in meta will be forever a pain
 ( due to Xmake proliferation and various backwards compat 
kludges which leak META into the generated makefile )
 I dunno, my stuff only ever handled it in the first place because 
ilmari complained at me
 https://metacpan.org/source/ETHER/Moose-2.1605/META.json 
<--- 2600 lines, maybe 20 of them have to do with actual installation 
and are expected to be read by *any* installer. The rest... is best 
effort anyway, why not separate it and stay happy

 [ META.json - metacpan.org ]
 hmm. I bet the original goal was for the META file to be fed into 
packaging systems
 right, which was in another era more or less ( no cpanm, no 
metacpan, no perl-pkg groups etc )
 perhaps rethinking "Meta for end-user install purposes" and 
"Meta for meta" would solve most of the recent repeated breakages by "oh 
downstream doesn't like this new thingymagic"


Cheers

Re: TRIAL dists shipping today

[Peter Rabbitson]

On 05/19/2015 07:23 PM, David Golden wrote:
As it turns out, my tuits mostly went to shipping *NEW* trial 
distributions for various reasons:


* Parse-CPAN-Meta -- fix a spurious 5.10 prereq
* CPAN-Meta -- release with changes since last release
* CPAN-Meta-Requirements -- changes to get tests passing on 5.6 again

So... while this was frustrating, it's an example of the system 
working in that rather then carelessly shipping these and hoping for 
the best, I've been more methodical before release and hopefully these 
new TRIAL dists will be suitable for stable.




My name is Peter Rabbitson, and I approve of this outcome.

In all seriousness: ++

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

[Peter Rabbitson]

On 05/06/2015 09:32 AM, Kent Fredric wrote:


On 6 May 2015 at 19:26, Peter Rabbitson ribasu...@cpan.org 
mailto:ribasu...@cpan.org wrote:


Sorry for the sidetrack


I was actually hoping for naming feedback :)

The names suggested seem amenable to me.

The only real problem I still have to resolve is what name we put 
non-article-oriented things like The Lancaster Consensus info under.




An unabridged version of any of the discussion outcomes isn't really 
something digestable as a standalone document anyway. So having them 
as-is on CPAN seems counterproductive to me. Nevertheless if this is 
desrable - ::Org::Toolchain::Minutes::(Lancaster|Berlin|Whathaveyou...)

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

[Peter Rabbitson]

On 05/06/2015 08:03 AM, Kent Fredric wrote:

This is something that has bothered me for a while.

We have a lot of standards and guiding principles, but a lot of it is 
all in our heads, wisdom one can only get by talking about it on 
toolchain, and/or breaking things and getting yelled at.


...

As such, I propose a very rudimentary idea:

Toolchain

This is the top namespace

Toolchain::Standards



First of all +1000 on the idea itself. I want to point out an 
alternative to the naming, simply because I have been thinking about 
something *very* similar for about 6 months now (and this email may in 
fact be the thing that gets me rolling).


The toolchain is not the only thing that has a body of knowledge to be 
documented. All organizations have that. All individual projects have 
that. And *individual authors* have things they would want to document. 
Not because of vanity, but because it is much much much simpler to link 
to a piece of text, instead of rehashing an argument for the 100th time.


Therefore I am urging you to think broader and go for:

Policy - short blurb what is this about
  Policy::Org - short sub-blurb what is this about
Policy::Org::P5P - pumpkin maitaned
Policy::Org::Toolchain - joint maintainership
  Policy::Project
Policy::Project::Moose
Policy::Project::DBIC
  Policy::Author
Policy::Author::AUTARCH - explicitly reserved (and non-squatable, 
PAUSE admins take action when needed)

Policy::Author::RIBASUSHI

Sorry for the sidetrack

Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

[Peter Rabbitson]

On 05/06/2015 02:19 PM, Neil Bowers wrote:
I’ve parked it for the moment, because Gabor has said he’s working on 
a CPAN notification system that he’d like to add this feature to.




Neil, it seems to me it is important to clarify if Gabor intends for his 
system to be fully and unconditionally open akin to metacpan, or is 
intended as a freemium service akin to stratopan. In case of the 
latter I do not consider this plan a viable way forward.

Language nit [ was: On the current Test::More-to-be ]

[Peter Rabbitson]

On 04/30/2015 11:23 PM, David Golden wrote:


an overwhelming majority was content with how things were handled...


I must admit a lapse of mine - until this morning I was embarrassingly 
unaware of the actual definition of the adjective 'content' [1]. I have 
been using it incorrectly to express a state of acceptance with 
tangible reservations, but not enough of them to express any 
objections. Or in other words on the negative side, between silent and 
dissenting, whereas it actually seems to sit on the positive side of 
silent, short of clear expression of joy.


The rest of my message remains as is.

[1] English as a 3rd language, work with me here.

Re: On the current Test::More-to-be

[Peter Rabbitson]

On 05/01/2015 11:23 AM, David Golden wrote:
On Fri, May 1, 2015 at 2:23 AM, Peter Rabbitson ribasu...@cpan.org 
mailto:ribasu...@cpan.org wrote:


On 04/30/2015 11:23 PM, David Golden wrote:


  It nonetheless implies (a) that few obstacles remain


I am claiming exactly this.  A hastily put together list of 5
points, without a hint of a mechanism of adding new points *is*
for all intents and purposes few obstacles remain.


They are not small obstacles.  And, via this list, we do have a 
governance mechanism for additional criteria.


What I would oppose, however, is an unbounded sequence of new 
obstacles introduced after all prior obstacles are overcome (without 
new evidence or concerns coming to light), as I don't think that's 
fair to Chad (or any developer).  That's a passive-aggressive way of 
saying no, which isn't good governance.


I absolutely agree with the last (only last) sentence. Hence why I tried 
to (but evidently failed miserably) to say no as early and as clearly 
as possible. I do not agree with the rest quotation, but that's 
water/bridge anyway, so pointless to spend time discussing further 
(again - I will publicly substantiate this upon request).


Instead of a you don't care, so I quit message (i.e. virtually 
rather than physically walking out of the room in protest), I'd have 
preferred one or more of these sorts of contributions:


* hey, given the changes in the code base, I'm not going to review 
anything until it's settled down more


* hey, in light of X, Y, Z new facts, here are some additional things 
I'd like to see on the punch list, does anyone else agree?


* hey, in light of the CPAN river conversation, I think others might 
agree with me now that the risks of change are too high.  Does anyone 
want to


I agree that within the narrow context of moving things forward a FYIQ 
response is the least desirable one. However within the context of the 
bigger picture, combined with my belief system I can no longer 
participate in this process without severely compromising my own 
integrity. Thus my only winning move is not to play.


This doesn't mean that my position itself is changing, I am simply 
electing (with a visible record) to stop advocating it in this instance. 
It is still there for the taking by anyone else sufficiently motivated.

Mischaracterization

[Peter Rabbitson]

Writing under a new thread, as this does not directly pertain to T::M.


On April 16th I participated in a closed door discussion about the
 current direction of this bedrock module. An overwhelming majority
 was content with how things were handled, thus the work is slated
 for continuation.



I resent that you continue to mis-characterize the discussion
whenever it suits your rhetorical purposes.  I urge you to check that
impulse and stay with the process as we discussed then, because the
rhetoric gets in the way of constructive discussion.


David, this is not the first time you are raising an issue with me
mischaracterizing a process. I assure you - the above is how I
personally see the discussion. It may not agree with your PoV, it may
not even agree with the PoV of the majority of the participants. This
doesn't make *my personal* takeaway any less valid. Even if you factor
in the (non-trivial) possibility of a mental deviation - it *still*
doesn't invalidate my perception of events. Continuously discounting
them as word play for rhetorical purposes is not constructive.


(1) fundamental design issues
...
With regards to #1, at the time, you had no objections to the
*design*.  Have you changed your mind?


I haven't changed my mind. I am not sure how we went from (paraphrasing 
nearly 10 minutes of the discussion about the hub):



The design is overengineered with at least one if not two levels of
indirection, optimizing for the wrong thing, instead of the 99.%
use case for perl testing


To


you had no objections to the *design*



If you feel that the above needs further discussion - take your time and 
think the answers through, none of this is burning. But *please* keep 
the discussion public.


Cheers

On the current Test::More-to-be

[Peter Rabbitson]

This is my (hopefully final) followup to the Test::More debacle.

On April 16th I participated in a closed door discussion about the 
current direction of this bedrock module. An overwhelming majority was 
content with how things were handled, thus the work is slated for 
continuation.


My position (for the record) remains unchanged - the current work being 
released as the 1.301xxx_xxx series has fundamental design issues, while 
the codebase itself was developed and continues being developed in a 
reactionary manner. It is therefore not fit for replacing the contents 
of the Test::More namespace, nor can be made fit without a 
restart-from-scratch design effort focusing on iterative improvements 
instead of a 2nd system rewrite.


Given the above, any review work that I carry out is going to fall short 
of addressing the fundamental issues, and as such would achieve nothing 
beyond making me complicit in this crime against the language. 
Therefore I am recusing myself from the $Level/$TODO review tasks that I 
volunteered to perform. I have not started pouring over the code in 
earnest, so I do not know whether there are showstopper bugs lurking 
underneath.


I want to specifically point out that I do not place any blame on Chad 
Granum. He was simply put on a collision course with a radically 
different engineering culture by the previous maintainer of Test::More, 
and subsequently got near-unanimous encouragement from the participants 
of QAH2015. Any and all preventable *silent* breakage that will result 
from this transition is unquestionably our responsibility.


Cheers

Re: Lancaster Consensus, deal with PUREPERL_ONLY=0

[Peter Rabbitson]

On Sun, Jun 01, 2014 at 08:15:20PM +0200, Jens Rehsack wrote:
 
 Am 01.06.2014 um 20:09 schrieb Peter Rabbitson rab...@rabbit.us:
 
  On Sun, Jun 01, 2014 at 05:59:16PM +0200, Jens Rehsack wrote:
  
  Am 01.06.2014 um 15:03 schrieb David Golden x...@xdg.me:
  
  The only thing specified in the lancaster consensus is what must
  happen if that command-line argument is true.
  
  I think making a distinction between 0 and undefined will be
  surprising to people and I would recommend against it.
  
  Given this point - how can we give people an instrument to force XS
  and fail if it's not available?
  
  As I mentioned before - you create a separate ::XS distribution, against 
  which the outliers declare dependencies. In general forcing XS when PP 
  is available is *always* *invairably* the wrong approach (which is why 
  they are called outliers above ;)
 
 The user must always have a way to enforce or fail. And not every
 distribution can be split into 2. So please forget the cases where
 it's possible to split and let's come back to the question:
 
 How can we enable the user/packager to make a clear choice?
 

Let me rephrase: making available a XS-only choice, when both PP ans XS are 
available is a mistake. Not just making the choice is a mistake, 
*presenting it* is a mistake in its own right.

Unless you have a clear use case that you didn't mention before ;)

Re: Lancaster Consensus, deal with PUREPERL_ONLY=0

[Peter Rabbitson]

On Sun, Jun 01, 2014 at 05:59:16PM +0200, Jens Rehsack wrote:
 
 Am 01.06.2014 um 15:03 schrieb David Golden x...@xdg.me:
 
  The only thing specified in the lancaster consensus is what must
  happen if that command-line argument is true.
  
  I think making a distinction between 0 and undefined will be
  surprising to people and I would recommend against it.
 
 Given this point - how can we give people an instrument to force XS
 and fail if it's not available?

As I mentioned before - you create a separate ::XS distribution, against 
which the outliers declare dependencies. In general forcing XS when PP 
is available is *always* *invairably* the wrong approach (which is why 
they are called outliers above ;)