RFC: BaseQuarantine.jl package

[tknopp]

This came up in #16590

What about introducing a BaseQuarantine.jl package that is used for stuff that should leave Base but where it is not yet clear:

• who wants to make a package of it
• who wants to maintain this package
• is there actually any interest within the community about this code?

This might have a little in common with Compat.jl but the scope is different.
If someone thinks that the stuff is within BaseQuarantine.jl is important and wants to make a dedicated package he/she can pick up the code and take over maintainership.
The advantage is that one decouples the removal and the point where a (maybe broader) package is created.

[tkelman]

Quarantine sounds like there's something wrong with the code. Archive maybe. If this isn't an actual package that's installable and usable, then what's the difference between this and recovering code from the git history?

[tknopp]

Yes. As a non-native speaker I did not came up with a better name. But kind of the idea is that the code should not be achieved there but it just that the code waits for people to take it and remove it from that package.

And to your second concern. Sorry this might not be well communicated. Of course this should be an installable and usable package and will help during the migration phase. We would tell people to simply use this package if they wonder where the removed Base functions are moved to.

[tkelman]

So it's just a matter of consolidating multiple base-to-package migrations into a single destination, instead of going to different small packages separated by specific functionality?

[tknopp]

Yes, exactly. Maybe what I describe is not an actual issue but currently if one wants to remove something from base one has two responsibilities:

• remove the stuff (and cleanup inside base)
• create a new package, take over maintainership (although one might not actually want this)

The last point is important because it seems to be not enough to just create the package but maintainership is an important aspect here.

Of course all this would only apply to cases where there is no obvious package that could take over the removed functionality.

[tkelman]

I see. That sounds more like a job for a common Github organization than a job for putting unrelated code in the same package? There is https://github.com/JuliaArchive which has so far been packages that either moved into Base (Markdown) or were never part of it.

[JeffBezanson]

I think the right approach is to leave things alone until we know where they are going, rather than first moving them to a holding area.

[tknopp]

@JeffBezanson The intention of #16590 to first look how things can be stripped out of base and then find a new home for the functions. In case there is a perfect home this is great, but what if not?

But I just realize, that the deprecation routine is kind of an alternative to this. Things are deprecated then removed. And if nobody cares to create a package for them, the functions were not worth it.