[Catalog-sig] (counter-)Proposal: Discouraging removal of packagers and revisions (Was Re: disallowing the removal of packages?)

Martijn Faassen faassen at startifact.com
Fri Jul 15 16:55:47 CEST 2011


On 07/15/2011 03:24 PM, Jim Fulton wrote:
[snip]
> 1. I think if package maintainers actually knew that removing old
> revisions did harm, most would not delete revisions or packages unless
> they thought it was necessary.  I think most people who remove old
> revisions do so for cleanliness, not appreciating that there is a
> downside.
>
> 2. I think a lot of people were turned off by the mandatory nature of
> the original proposal. (I now regret my +1 of that proposal, made in
> support of the sentiment behind it, but not taking into consideration
> how it runs counter to Python culture.)

[snip proposal]

Sure, I already indicated a +1 earlier.

I tried to sketch out the use cases behind my proposal but people 
focused on what turned them off.

So thinking about this more, what about an extra feature that focuses on
communication?

What I'm interested in is the following:

* reducing the incidence of suddenly removed packages (the message might 
help)

* being aware that packages are removed

Others also expressed an interest in having the following:

* having a way to deprecate old releases or whole packages

So what if we provided communication channels for that?

if a package or release is removed by an author, they could be asked to 
give a reason ("botched upload!", "legal reasons"), whatever.

Then there'll be a feed which shows recent deletions along with the 
reasons. There'd be some machine readable components in this feed too.

Also useful for tools would be way to access the total list of all 
deletions.

This could also be expanded to a "deprecation message". Instead of 
removing a package, an author can add a deprecation message to a 
package. This could also be on a feed.

This way we have a communication channel where we can be informed about 
what's going on. In response both humans as well as automated tools 
could take action. You could for instance have a scanning tool which 
looks at installed packages and tells you which ones are deprecated or 
removed.

It doesn't offer the same guarantees as a perpetual mirror would, so it 
doesn't quite solve the same use cases. But it would make it possible 
for people to properly collaborate and communicate about this kind of thing.

I'm not proposing that any of the existing client-side tools are 
adjusted to support any of this.

tldr: we've got a feed and index for packages. what about a feed and 
index for removals and deprecations?

Regards,

Martijn



More information about the Catalog-SIG mailing list