Explain how to remove modules from the ecosystem about ecosystem HOT 14 CLOSED

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.

from ecosystem.

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.

from ecosystem.

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.

from ecosystem.

What about closing the ecosystem and making cpan6 the only recognized collection? That, I believe was the stated goal?

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:

2 |Zef::Repository::Ecosystems<p6c>|panda:ver<2016.02>                                     |[DEPRECATED] A module ma...

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

1. The author of the module decides to do so, by deleting the line in META.list or removing it from CPAN.
2. If the author marks it as "DEPRECATED" or "SUPERSEDED" in the META6.json description field, it will be removed after consultation with said author.
3. The current maintainer from the module (which migh be different from the author) requests it as PR or request from the ecosystem maintainers"

Please don't consider this final. it's just a proposal and a basis for discussion.

from ecosystem.

from ecosystem.

What about closing the ecosystem and making cpan6 the only recognized collection?

Why deliberately destroy a working ecosystem? I don't want to move all of my 47 modules to a system I consider inferior.

That, I believe was the stated goal?

It never was. All that ever existed was an erroneous commit in the docs.

It seems pretty obvious that the author

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.

Could the DEPRECATED mark be a sign for the ecosystem administrator to delete it?

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.

I think this ticket should be closed.

👍

from ecosystem.

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.

from ecosystem.

@JJ DO you know what the 'C' in CPAN stands for?

from ecosystem.

@stmuk @rafaelschipiura so what's precisely your answer to:

Explain how to remove modules from the ecosystem

And

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.

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?
And you say that we shouldn't be removing stuff from META.list even if it's DEPRECATED, and clearly marked so by the author. But should we do nothing? Can we not tell the author the available options? (Including removing it from the ecosystem). Right now there are less than half a dozen distros like that. What if, in the future, there are 300, and there are 10000 modules? Will this policy scale?

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.

from ecosystem.

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.

from ecosystem.

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.

from ecosystem.

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.

from ecosystem.

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.

from ecosystem.

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.

from ecosystem.