forked from daxim/Module-CPANTS-Analyse
-
Notifications
You must be signed in to change notification settings - Fork 15
/
TODO
173 lines (124 loc) · 6.63 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
#-----------------------------------------------------------------
# TODO Module-CPANTS-Analyse
# $Rev: 409 $
# $Date: 2006-09-14 19:42:31 +0200 (Thu, 14 Sep 2006) $
#-----------------------------------------------------------------
#-----------------------------------------------------------------
# BUGS
#-----------------------------------------------------------------
Robert 'phaylon' Sedlacek <[email protected]>
Meldung, dass 'has_proper_version' nicht bestanden wird.
http://rt.cpan.org/Ticket/Display.html?id=21370
Win32 test fail: analyse.t, analyse_afs.t, calc.t, testfile.t
Moose and MooseX turn on strict, so count Moose[X] as use_strict
The "ownership of a modules does not seem to get updated"
e.g. still shows DAGOLDEN even tough it should be ADAMK
http://cpants.perl.org/dist/external/Perl-Dist-Strawberry
#-----------------------------------------------------------------
# New Metrics
#-----------------------------------------------------------------
- no_boilerplate
- has_valid_filenames
- declares_dependencies
- no_open_bugs
- no_old_open_bugs (older than a year?)
- license_is_actual might be a good addition, like "copyright 2001-2002" is rather outdated
- add list of modules that fail the use_warnings to $d->{error}{use_warnings}
- same for use_strict
- Allow the Debian and/or the Fedora packagers to "manually" report problems they
encounter with certain packages directly from their systems.
So if there is a module that cannot automatically packaged (or tested?) because
they are interactive (in the wrong way) or they need network access...
On the Debian list it was discussed that they might start saving this information
from themself and then export this information with the rest of the data about
packages.
- Signature checking ?
- has_rating ?
- relation of subs to lines of code ?
- easily_repackagable
- easily_repackagable_by_debian
- easily_repackagable_by_fedora
on http://www.perlfoundation.org/perl5/index.cgi?cpan_packaging
there are guidelines for module authors to make their modules easily
repackagable by downstream distros.
It would be great if we could add as many to CPANTS as possible.
Some we can check without executing code.
Others might be verified by the CPAN Testers, reported by the tools
and then collected from the reports by CPANTS.
- version_number_is_sane
There are several issues here:
1) Is the version number sane for perl (I think there is a metric already)
2) Is the version number sane for Debian/RedHat (they have different meaning of sane)
3) Is the scheme of the version numbers stable? (In Debian they don't like when ppl are
changing from D.DD to a D.D scheme or vice versa.
1.1.1 is not considered correct by MakeMaker but it is currently accepted by CPANTS
http://cpants.perl.org/dist/kwalitee/Sys-HostIP
http://www.nntp.perl.org/group/perl.qa/2007/12/msg10025.html
- has_same_version_number_in_all_files ???
Some people will argue that when one of the files does not change, there is no
need to change its version number. So this might not be a good metric.
- no_bugs_in_freebsd
- has_patches_in_freebsd
The Debian and FreeBSD ppl will provide the interface for this -probably a csv file
that can be fetched using http.
This should be (an optional?) negative metric in case the module is
included in FreeBSD or Debian but it had to be patched.
(Maybe we need to make sure that we set this negative metric only when the
module versions are the same so we won't penalize a module because XYZ
has not yet integrated the newer version that possibly already includes
the patch.
- We might even have an optional metric to show that
"the latest version of the module is included in Debian/FreeBSD etc".
This will be lost every time a new version of a module is released but
over time it will become ok again.
(in xt/ or in t/ and the same file has RELEASE_TESTING in it)
- has_no_indirect_code
Check the source code (and/or) the documentation if you see
new Module::Name anywhere mark the metric as failed.
- all_links_in_the_documentation_still_exist
- declares_minimal_version_of_perl
It has "use N" somewhere in the Makefile.PL and/or Build.PL and/or the source code.
(and they match to each other :-)
(No specific N should be required)
- "something about has good perl code"
(e.g. if uses 3 param open but does not say use perl 5.6 or similar)
- has_humanreadable_license
the actual name of the license (perl, etc.) is in the database, use it
Module::License::Report integration
(though I am not sure if that should mean the main .pm
file only or all the files or what)
- licenses_are_consistent
Locate places where hard-coded pathes to perl (or other files?)
are:
>
> my @cmd = qw{/usr/bin/perl -Ilib -MPod::HtmlEasy -e};
actually try to locate places where perl is called instead of $^X
<@Tux> has no open bugs in RT older than 2 months
<@Tux> and debian shipped last version is only ok is last version is older than 3 months
#-----------------------------------------------------------------
# Other Stuff
#-----------------------------------------------------------------
- include more dists in test (for better test coverage)
- improve NeedsCompiler (see its TODO)
- Perl Critic report:
As this is not really in the consensus probably it is better not add it as
a metric now but it might be nice to run it on each module
(starting at level 5 ) and display it along with the metrics.
Maybe it can be added as an optional metric.
- http://cpants.perl.org/author/search should also work on partial names
adding % % automatically (or at least tell the users on the search page to
use % as wildcards.
- create stats (or metrics) for distros that were uploaded recently with failing metrics.
e.g. the fact that 9920 Distributions failing 'metayml_has_license' is skewed by the
many modules that were not updated in the past 1-2 years. It would be more important
to see the number of modules uploaded in the last year without metayml of without license
field in the metayaml.
- Export the kwalitee of each distro in a csv file like so it can be easily integrated into
other web sites such as the search engines.
- Export the kwalitee of each distro in a csv file like so it can be easily integrated into
other web sites such as the search engines.
- Create a hierarchical report (aka CPANDepth) showing all the dependencies
their kwalitee, their age, their license (the name of the license from META.yml for now)
- honor the META.yml key no_index. See RT#32777
- Display the version of CPANTS used for indexing and show the date when the last update
was executed. Maybe do so per distribution?