Melpa: Need a policy for removing old packages

[milkypostman]

Given a number of issues about removing old packages lately: #4372, #4382, and #4379 I think we should try to adopt some policy about how we will choose which packages to remove.

I don't feel bad about some error here; a package appears to be old (not updated a lot) and recent downloads are low, then a package gets removed and eventually someone complains and we have to revert the commit. It's not really so bad to have to do this to keep things curated.

I will work on #4376 and once that is done we should have better stats on what is still actively being used.

[lunaryorn]

@milkypostman Mmh, I'm not sure whether you're actually in a position to have a policy. After all, anyone can just delete a repo from their Github account, and MELPA would end up with nowhere to build from, forcing it to remove the recipe as well, right?

As for the requests that I opened (#4379 and #4380) I _will_ eventually delete these repositories or make them private, whether MELPA decides to remove them or not, for they _are_ unmaintained and outdated, and there's no point keeping them around. To be honest, I didn't open these PRs to kind of offer a choice of keeping them, but just to raise awareness and give MELPA a grace period before making your builds fail.

[milkypostman]

I was thinking about the case prior to repo being deleted. In cases where
the repo still exists but the package is just out of date and not used.

On Wed, Nov 2, 2016 at 02:49 Sebastian Wiesner [email protected]
wrote:

@milkypostman https://github.com/milkypostman Mmh, I'm not sure whether
you're actually in a position to have a policy. After all, anyone can just
delete a repo from their Github account, and MELPA would end up with
nowhere to build from, forcing it to remove the recipe as well, right?

As for the requests that I opened (#4379
https://github.com/melpa/melpa/pull/4379 and #4380
https://github.com/melpa/melpa/pull/4380) I _will_ eventually delete
these repositories or make them private, whether MELPA decides to remove
them or not, for they _are_ unmaintained and outdated, and there's no
point keeping them around. To be honest, I didn't open these PRs to kind of
offer a choice of keeping them, but just to raise awareness and give MELPA
a grace period before making your builds fail.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/melpa/melpa/issues/4384#issuecomment-257818306, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACUsu30uig9aOV9vwqTzUV8Jah6zrcrks5q6FyngaJpZM4Kmz7p
.

[lunaryorn]

@milkypostman Ah, sorry, misunderstood the issue then. Sorry for the noise.

[tarsius]

I don't feel bad about some error here; a package appears to be old (not updated a lot) and recent downloads are low, then a package gets removed and eventually someone complains and we have to revert the commit. It's not really so bad to have to do this to keep things curated.

So the policy would be "If we feel something isn't maintained anymore and also not used anymore, then we remove it. If it turns out that it actually still used, then we add it back." Seems reasonable and to match what is already being done. I would only add "justification for the removal has to be given in the commit message".

[xiongtx]

So the policy would be "If we feel something isn't maintained anymore and also not used anymore, then we remove it. If it turns out that it actually still used, then we add it back."

Shouldn't the criterion be "does the package still work with the minimum version of Emacs we require"? If a package works fine, but the maintainer hasn't touched it in 2 years, why should it be removed?

[purcell]

Shouldn't the criterion be "does the package still work with the minimum version of Emacs we require"? If a package works fine, but the maintainer hasn't touched it in 2 years, why should it be removed?

Yeah, agree: I'm a bit less gung-ho about deleting old packages. If their upstreams disappear, or if their authors declare them obsolete, then it's worth considering removing them IMO.