Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2017-06-26

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:08 metacpan joined #metacpan
01:08 metacpan [metacpan-client] stevieb9 opened pull request #90: Revdep test file (master...revdep_test) https://git.io/vQ3aw
01:08 metacpan left #metacpan
02:14 karjala_ joined #metacpan
02:39 [Tux] joined #metacpan
05:29 brunoramos joined #metacpan
05:29 karjala_ joined #metacpan
05:35 nakiro joined #metacpan
10:50 neilb joined #metacpan
15:07 ilbot2 joined #metacpan
15:07 Topic for #metacpan is now https://github.com/metacpan/metacpan-api/wiki/MetaCPAN-V1-announcement-and-migration-plan | MetaCPAN Developer VM https://github.com/metacpan/metacpan-developer | Chat logs available at http://irclog.perlgeek.de/metacpan/ | Can't find your module on MetaCPAN? https://metacpan.org/about/missing_modules
15:36 jdv79 the changes parser is strict
15:36 jdv79 data selector 1.02 is showing 1.01s changes because of it
15:51 Khisanth joined #metacpan
16:09 Grinnz jdv79: no, that's because the dist has a broken META.yml that says the dist version is 1.01
16:09 Grinnz yay Module::Install!
16:11 Grinnz jdv79: also, general practice is to put more recent changelog entries at the top fyi
16:12 jdv79 hmm. ok.
16:13 jdv79 isnt the meta yml kicked out by m::i?
16:13 Grinnz it should be generated when building the dist, yes
16:14 Grinnz this isn't the first time i've seen M::I dists specifically not have an updated version though, so I'm blaming M::I first :P
16:16 mst IIRC it's entirely possible to 'make dist' without having re-run Makefile.PL
16:17 mst M::I is not strong on safety features
16:33 jdv79 oh:(
16:35 Grinnz also see https://metacpan.org/pod/Module::Install#WARNING if you havent seen all our recent complaining about it
16:46 neilb joined #metacpan
16:51 Grinnz hmm, was there ever a discussion about changing how module/release pages only prominently show the latest uploader? i can't find an issue for it or anything
16:51 Grinnz i think the indexing of perms was partially to help that?
16:53 haarg it's been discussed a number of times before
16:53 haarg part of the issue is that none of the choices will be obviously more correct
16:54 Grinnz sure
16:54 Grinnz i just have a faint recollection that it arrived at some nice conclusion, but i have no idea where it occurred
17:03 haarg https://github.com/metacpan/metacpan-web/issues/940
17:03 haarg there may be other tickets
17:08 Grinnz someone made this mockup at some point http://buzzword.org.uk/2014/credits-stuff/MooseX-Types.html
17:08 Grinnz i assume it was ether
17:10 Grinnz i'm not sure if thats exactly how i'd like it laid out, but i think it's an improvement to have either the listed authors or the 06perms entries there prominently
17:10 ether nope not me
17:13 jcast joined #metacpan
17:14 haarg release manager isn't currently information we have or have specced
17:15 Grinnz yeah i'm not sure about that terminology
17:15 Grinnz i'd prefer to keep it simple: maintainers (referring to permissions) or authors
17:16 Grinnz it's difficult to say which of those is more important to show
17:18 Tempesta joined #metacpan
17:45 oalders we have 06perms now, so we could start adding co-maints to the release pages
19:34 karjala_ joined #metacpan
20:47 ether there are four separate pieces of data we can make use of:  1. who has firstcome for the distribution (from 06perms); 2. who has comaint for the distribution (from 06perms); 3. who did the last release (PAUSE id on the tarball); 4. people listed as contributors (x_contributors metadata)
20:51 Grinnz ether: 5. people listed as authors (metadata or pod)
20:52 Grinnz for the sake of "who wrote this", 5 is the most important; for the sake of "who do i complain to", 1+2+3 are the most important
20:54 Grinnz i'm fine with contributors being an "extra" list like it currently is, that's not really important for what end users need
20:55 Grinnz (or better than "who do i complain to", perhaps "who is responsible for this")
21:11 mickey we have the contributors list in an ES type as well
21:25 ether Grinnz: right, the authors in metadata might be significant.  I wouldn't parse pod though; starting down that road is madness
21:25 ether if it's meant to be machine-parseable, put it in the file that the machine looks at
21:25 Grinnz i wouldn't either, but it's an option
21:25 ether (I know that ship has sailed regarding licences but let's not make things worse)
21:26 Grinnz well licenses are another matter, since they're relevant to legality :P
21:27 Grinnz CPAN would be such a mess legally if people couldn't just put "same terms as perl"
23:33 communicator joined #metacpan

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary