Support meta field for copying permissions from another module
x_authority allows you to specify another author to be given first-come permissions on new modules you upload in a given dist. This allows the authority user to manage all of the permissions for a dist. It isn't sufficient for cabal maintained dists though, because only the uploader and the designated authority are given permissions, not the other co-maints.
What would work better would be a way to specify a module to copy permissions from. This would include the first-come permissions, as well as any co-maint permissions. This is something that could be done manually by the uploader (assuming x_authority wasn't set) but can take a lot of time.
Maybe x_copy_permissions => "Module::Name"?
Now that distribution names are linked to module name permissions anyway, what if x_authority just copied the permissions from the module name matching the distribution name to any new modules rather than adding another "x_" field?
Yes, it's just my distributions, but: http://grep.cpan.me/?q=x_permissions_from
what if x_authority just copied the permissions from the module name matching the distribution name to any new modules rather than adding another "x_" field?
By default? I expect we'd have to exempt the distributions that are already grandfathered due to not having a module that matched the distribution name.
It seems confusing if setting x_authority: "cpan:HAARG" started copying a bunch of other permissions. Would we just be ignoring the value entirely?
looks like I never mentioned on here that I've been adding this metadata to all my released distributions for quite a while, via: https://metacpan.org/pod/Dist::Zilla::Plugin::AuthorityFromModule (see the MOTIVATION section of pod for more relating to this ticket).
Splendid motivation section, thanks for that. What is not so beautiful: 50 people x 50 modules => 2500 permissions. From a recent discussion with RJBS it seems a little known fact that pause supported groups for ages, we just used the term mailing lists at that time: https://pause.perl.org/pause/authenquery?ACTION=show_ml_repr. The interface was always ugly and probably is the reason it never took off, but at least it was O(N).
That interface also appears to only be available to PAUSE admins.
Is having 2500 permissions a significant problem somewhere? And for most dists there wouldn't be anywhere near that many.
The metadata sketched out in this ticket doesn't make the permissions db any larger than it is today -- it simply attempts to address the problem of inconsistent permissions arising on a distribution, without having to involve the PAUSE admins in fixing things manually.
I did a quick analysis of the permissions db, to see the distribution between modules and number of maintainers:
# number of maintainers => matching modules
$VAR1 = {
'01' => 151379,
'02' => 28799,
'03' => 6511,
'04' => 7452,
'05' => 3322,
'06' => 1672,
'07' => 1755,
'08' => 643,
'09' => 228,
'10' => 252,
'11' => 275,
'12' => 104,
'13' => 87,
'14' => 109,
'15' => 24,
'16' => 42,
'17' => 35,
'18' => 10,
'19' => 82,
'20' => 193,
'21' => 49,
'22' => 62,
'23' => 53,
'24' => 44,
'25' => 34,
'26' => 12,
'27' => 3,
'28' => 2,
'29' => 3,
'31' => 3,
'32' => 1,
'33' => 1,
'37' => 2
};
The code:
use strict;
use warnings;
# read ~/.cpanm/06perms.txt from STDIN and place modules in buckets for how many maintainers each has:
my %modules; # module => authors count
while (my $line = <>) {
chomp($line);
next if $line =~ /\s/;
my ($module, $author, $perm) = split(/,/, $line, 3);
next if not $module;
++$modules{$module};
}
my %author_count;
foreach my $module (keys %modules) {
++$author_count{ sprintf('%02d', $modules{$module}) };
}
use Data::Dumper;
local $Data::Dumper::Sortkeys = 1;
print Dumper(\%author_count);