Explain how to remove modules from the ecosystem #404
Comments
|
The idea of an "ecosystem administrator" deleting modules simply because they are marked as "DEPRECATED" is bizarre. People could have good reasons for viewing such source for historic reasons or educational. The only situation where it could be permissible for us to remove other people's modules from the eco-system is if the content is illegal or malware. |
|
@JJ DO you know what the 'C' in CPAN stands for? |
|
@stmuk @rafaelschipiura so what's precisely your answer to:
And
I'm just proposing several alternatives. We should choose one, and an author should know them, as well as the "administrators" (whoever they are). This should be enforced down the line. Just imagine that someone deletes a distro on which other distros depend. Should we leave it at that? What if an author that is different from the one that added the line to META.list deletes it. Are we going to check? What if someone who is not an author does it? I am not trying to impose my opinions, just put them on the table. At the end of the day, what I want is to reach a consensus and write it down so that everyone knows what's the deal. |
|
Perl (in 5 and 6 versions) isn't anything to do with anything being "enforced down the line". The modules are owned by the copyright holders not tool chain helpers so yes we should do exactly nothing (apart from one or two extreme cases I mentioned above). Any sort of attempted micro management by helpers (more accurate than "administrators") trying to second guess what the module owners want isn't going to be welcomed by the Perl community. We aren't bossing people around but trying to aid them. This sort of hands off policy has generally worked well with Perl 5's CPAN and its thousands of modules and will scale exactly because its "hands off" . It should be self-evident to anyone familiar with the loose decentralised Perl philosophy (we aren't the Apple App store). A consensus exists and doesn't need to be written down (we aren't a bureaucracy). I think this ticket should be closed. |
|
But CPAN allows authors to delete their modules via the PAUSE interface. That's still available if people upload Perl 6 modules via that interface. But there are still a few who just change a line in META.list. |
|
The few changing the META.list do it based on PR from the module owner. This works for both adding and removing modules. Helpers don't "own" those lines but the originators of the PRs. |
|
In some cases, no PR is needed because people have a commit bit set. And, while that is common sense, it would be much better if it was consensus-driven common sense written anywhere. Which, for the time being, it is not. |
|
What about closing the ecosystem and making cpan6 the only recognized collection? That, I believe was the stated goal? Why do we allow new modules to be added to the ecosystem? If authors don’t move them to cpan6 after some time, fork them and put the new one in cpan6. While it does exist, move it to a more restricted repo (maybe rakudo) where it’s not as easy to add to it or modify the data. |
I am pretty sure that it was mentioned somewhere, and it looks quite reasonable. But that's another reason why we need some written policy. What if it's moved to CPAN but the META.list entry is still kept? What if the original maintainer is unavailable and does not care about moving stuff to CPAN6? While the principle of "the author of a line in META.list owns that line" seems reasonable as a fallback, there are many other possibilities out there. It's not as if we're deleting some stuff from the whole wide internet, just making it unavailable when one does zef search. Right now, if one searches for Panda, it says: So is there any point in showing this result to the whole community? Once again, I'm not saying that the policy should be "As soon as some module is marked as deprecated or considered deprecated by the Ecosystem cabal, it will be inmediately deleted". What I'm proposing is something along the lines of: "A module will be deleted from the ecosystem if
Please don't consider this final. it's just a proposal and a basis for discussion. |
|
I understand @stmuk’s position, but I don’t agree with all of it. The module may belng to the author, but the public cpan repository belongs to the community, and any module to be listed there is forced to abide by certain rules (the price of being listed there). The META6 (and its format) is part of the rules. |
|
I get @stmuk's point, but the danger is a graveyard ecosystem, where most of the modules are abandoned experiments. Perl 5 could get away with it because of it's popularity and lack of alternatives. Today, Perl 6 will take a longer time to get there. In @JJ's proposal no one is removing modules but the author/maintainer him or herself. |
|
Neither DEPRECATED nor SUPERSEDED mean DELETEME. People should be able to use deprecated modules if they choose to even if you don't want them too. I wouldn't expect to be contacted over a DEPRECATED module. I've no objection to adding DELETEME but changing the usual meaning of words is Bad. |
|
El dom., 29 jul. 2018 a las 13:24, Steve Mynott (<notifications@github.com>)
escribió:
Neither DEPRECATED nor SUPERSEDED mean DELETEME.
No one has said that. In my proposal above, it means "check with the author
to see what can be done"
People should be able to use deprecated modules if they choose to even if
you don't want them too. I wouldn't expect to be contacted over a
DEPRECATED module.
They can still download them from GitHub and use them as much as they like.
Only they wouldn't be available as search results from zef or from
modules.perl6.org
I've no objection to adding DELETEME but changing the usual meaning of
words is Bad.
If that's the consensus, it should be written down. "The usual meaning" is,
actually, not very meaningful, because DEPRECATED for me, in all caps,
means "why would anyone want to be shown this in search results?". But I
would go for any solution for a procedure for removing stuff from the
ecosystem as long as it's written down and everyone is (roughly) happy with
it.
|
Why deliberately destroy a working ecosystem? I don't want to move all of my 47 modules to a system I consider inferior.
It never was. All that ever existed was an erroneous commit in the docs.
Yes, it is pretty obvious. I don't understand why we need to implement any sort of ecosystem police. There will be bad, broken, and outdated modules in our ecosystem. It's just a fact of life. We don't need to do anything about it. Second-guessing authors' decisions will just piss people off when you guess wrong and hardly has any benefit. If you want to avoid "graveyard ecosystem", it's much easier to simply mark popular modules in active development, not to have volunteers make arbitrary decisions based on ambiguous information. In fact, we already have that information for p6c ecosystem: stars and last commit date.
No. That would break all the software that still uses that module. The whole point of deprecating software instead of deleting it is to allow the users ample time to update to alternatives, without breaking their code.
👍 |
Right now if all copies from CPAN are removed, I guess it's removed here too. However, it's not written anywhere how to remove modules from the ecosystem, or who can do it.
It seems pretty obvious that the author is the one that should do it, and probably via the same method that was used to list it: modify META.list; however, it's not really written anywhere.
In some cases, modules are listed by the author as "DEPRECATED", but they are still available in the ecosystem. It's not clear if that's the author's intention or there was simply no explicit way of removing them. Could the DEPRECATED mark be a sign for the ecosystem administrator to delete it?
But, anyway, I guess it's better if it's clearly written, in the same way that module adoption is explicitly written here.
The text was updated successfully, but these errors were encountered: