Open wei2912 opened 5 years ago
Git is our archive. I don't see a good reason to maintain a "modules/archive" directory.
Yeah, I agree with that. @wei2912 mind if I just delete the obsolete files?
@Androbin @nu11us fair point, a delete of the modules should be more appropriate.
Personally, I would prefer nsfw modules to just be default disabled under an nsfw flag in the config.
They do appear publicly on this repository though and to anyone working on the IRC bot.
Having them, especially rule34.py
, out in the open to a competition of 13-17 year olds doesn't sound appropriate, even if they are disabled.
I'm in favor of outright deleting the NSFW modules and perhaps even other modules that never get used, like mylife.py
.
That's in the pull request as of now. I've also uploaded a script in my task that gives the usage of all the scripts from the logs since around 2010.
Usage as of now with a few false positives https://pastebin.com/yHYVE1ud
Output: https://pastebin.com/mBTsYF1d
Going along with what @wei2912 said, what about removing all modules used less than X times? (He suggests X=50, I think X=20 would be better, thoughts?) Caveat: there are some modules that aren't actually 'called', but rather respond to text in the channel. For example, whenever someone says "particle", begiak responds. These should not be deleted.
I considered that, but the some of the unused modules still have some utility or charm. Looking through the output pastebin, I think it would have to be around n=5 as the majority of all the commands are under 20.
The ones that have "charm" can be picked out by hand but I think it's fine to remove the majority of them. @jonorthwash may have a different opinion on this, though. Meanwhile could you compile a list of the ones below 20 and see whether any of those are actually dependencies for others, have a 'reaction' like particles, need to be kept for some other reason, etc.?
Will be updating this with reasoning/dependencies
Command | Uses | Deleted? | Reason to Keep | |
---|---|---|---|---|
archwiki | N/A | Yes | N/A | |
autojoin | 0 | No | Utility | |
checkMessages | 0 | No | Utility | |
f_weather | 0 | Yes | N/A | |
foodvote | 0 | Yes | N/A | |
generate | 0 | No | Utility | |
harglebargleP | 0 | No | Charm? | |
mailing list reporter | 0 | No | Utility | |
nightnight | 0 | No | Charm? | |
perword | 0 | No | Dependency | |
pointing | 0 | No | Utility | |
retrieve_commit | 0 | No | Utility | |
uderp | 0 | No | Charm? | |
unsupervised | 0 | No | Charm? | |
vtluug | 0 | Yes | N/A | |
bytes | 1 | No | Dependency | |
food | 1 | Yes | N/A | |
get_recent_commit | 1 | No | Utility | |
identlang | 1 | No | Utility | |
information | 1 | No | Utility | |
particles | 1 | No | Dependency | |
pester stop | 1 | No | Utility | |
quit | 1 | No | Utility | |
upgrade | 1 | No | Utility | |
wadsworth | 1 | Yes | N/A | |
calccoverage | 2 | No | Utility | |
ethnologue | 2 | No | Utility | |
head | 2 | No | Utility | |
linx | 2 | No | Utility | |
apystats | 3 | No | Utility | |
bargle | 3 | No | Charm? | |
hargle | 3 | No | Charm? | |
nsfw | 3 | No | Utility | |
part | 3 | No | Utility | |
suggest | 3 | No | Utility | |
choose | 4 | No | Utility | |
udmurt | 4 | No | Charm? | |
wuvt | 4 | Yes | N/A | |
bothug | 5 | No | Charm? | |
hs | 5 | No | firespeaker | |
fcc | 6 | No | firespeaker | |
join | 7 | No | Utility | |
stache | 7 | Yes | N/A | |
analyse | 8 | No | Utility | |
harglebargle | 10 | No | Charm? | |
stats | 12 | No | Utility | |
ety | 13 | No | Utility | |
pesters | 13 | No | Utility | |
slogan | 13 | Yes | N/A | |
botslap | 14 | No | Charm? | |
following | 14 | No | Utility | |
pester | 14 | No | Utility | |
commit | 16 | No | Utility | |
imdb | 16 | Yes | N/A | |
unfollow | 17 | No | Utility |
I'd keep fcc
. It's off-topic for #apertium, but it's a useful module and it still works. Some other group might benefit from it in the future.
Will add it back momentarily. Any others?
I would argue that vtluugwiki.py
(and the other wikis) was reduced to so little extra code that it's near zero maintenance.
Instead of removing it, we might as well have a combined wiki module which enumerates (with very little overhead) the set of wiki URLs (+names).
Then again, only the general wiki code that's already used in/by/for apertium_wiki.py
will have to be maintained.
I suggest keeping them for now and creating another ticket (potential GCI task) for implementing such changes.
Yeah, I was on the side of keeping them at one point due to potential, but they still remain unused. Perhaps, we could remove them for now until a combined wiki module is implemented? That would allow me to finish this task and have another GCI task for that.
Consider the remaining modules here:
| Module | Reason for Removal | | archwiki.py | We don't even use ArchWiki | | eleda.py | Doesn't seem like we've ever use it | | imdb.py | kinda useful but not sure if it's working | | lastfm.py | do we really want to know what users are listening to |
I'm guessing ArchWiki usages are probably Apertium Wiki usages.
That explains it.
Just removed ArchWiki in the PR.
Closing as the PR has been merged.
Wait, were the imdb and weather modules deleted too?
I suggest keeping them for now and creating another ticket (potential GCI task) for implementing such changes.
+1, was this ticket opened?
Yeah, imdb was broken and weather was rarely used.
imdb was broken
Ah, okay.
and weather was rarely used.
That's a good one to keep around though... And it could be more useful to another community. Is there an easy way to bring it back?
Of course; I can just add another pull request or someone can just re-add the module to the folder.
@nu11us, could you just add another PR?
Given that upstream has been archived, we may want to relook through all the modules and remove those that we won't plan to actively develop.
So, should we really keep the ones listed as "Charm"? Like, is having .bot*, harglebargle, noexceptions, etc. really useful?
Look through the list of modules and determine which ones can be deprecated. Modules to be deprecated should either be 1. very rarely used, 2. NSFW, 3. unrepairable or 4. obsolete. Deprecated modules should be shifted into "modules/archive".