New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fast deletion interface #163

Open
karenetheridge opened this Issue Apr 18, 2015 · 5 comments

Comments

Projects
None yet
5 participants
@karenetheridge
Contributor

karenetheridge commented Apr 18, 2015

from QAH Berlin 2015: we need an interface to delete distributions from PAUSE that takes effect sooner than in 3 days.

(there are concerns about whether backpan will always have a chance to archive the dist, which should be examined.)

@kentfredric

This comment has been minimized.

Show comment
Hide comment
@kentfredric

kentfredric May 10, 2015

I suggest there may be a desire for a "Also skip backpan" option for very fast deletes where a backup copy is undesirable, for example, cases where private details leak in to a release, this gets it killed before replication happens and without needing to get proper takedowns performed manually.

Without that option, I would desire some sort of priority signal sent to the backpan mirror to make that version backup happen ASAP, with PAUSE checking backpan every hour or so for slated removals to be replicated, and then nuke them when backpan has mirrored it.

kentfredric commented May 10, 2015

I suggest there may be a desire for a "Also skip backpan" option for very fast deletes where a backup copy is undesirable, for example, cases where private details leak in to a release, this gets it killed before replication happens and without needing to get proper takedowns performed manually.

Without that option, I would desire some sort of priority signal sent to the backpan mirror to make that version backup happen ASAP, with PAUSE checking backpan every hour or so for slated removals to be replicated, and then nuke them when backpan has mirrored it.

@andk

This comment has been minimized.

Show comment
Hide comment
@andk

andk May 10, 2015

Owner

On Sat, 09 May 2015 20:21:53 -0700, Kent Fredric notifications@github.com said:

I suggest there may be a desire for a "Also skip backpan" option for
very fast deletes where a backup copy is undesirable, for example,
cases where private details leak in to a release, this gets it
killed before replication happens and without needing to get proper
takedowns performed manually.

Without that option, I would desire some sort of priority signal
sent to the backpan mirror to make that version backup happen ASAP,
with PAUSE checking backpan every hour or so for slated removals to
be replicated, and then nuke them when backpan has mirrored it.

This desire can only be rejected, it is unfulfillable. CPAN
infrastructure is faster than you seem to believe. Every file you upload
is squirreled away before anybody can click any delete button.

andreas

Owner

andk commented May 10, 2015

On Sat, 09 May 2015 20:21:53 -0700, Kent Fredric notifications@github.com said:

I suggest there may be a desire for a "Also skip backpan" option for
very fast deletes where a backup copy is undesirable, for example,
cases where private details leak in to a release, this gets it
killed before replication happens and without needing to get proper
takedowns performed manually.

Without that option, I would desire some sort of priority signal
sent to the backpan mirror to make that version backup happen ASAP,
with PAUSE checking backpan every hour or so for slated removals to
be replicated, and then nuke them when backpan has mirrored it.

This desire can only be rejected, it is unfulfillable. CPAN
infrastructure is faster than you seem to believe. Every file you upload
is squirreled away before anybody can click any delete button.

andreas

@kentfredric

This comment has been minimized.

Show comment
Hide comment
@kentfredric

kentfredric May 10, 2015

This desire can only be rejected, it is unfulfillable. CPAN infrastructure is faster than you seem to believe. Every file you upload is squirreled away before anybody can click any delete button.

I don't mean that it will be "flawless", you will still of course need some other kind of ass-cover for everywhere else it replicates to.

Its just a "minimize damage" step. Though I guess if its already hit a primary mirror then you're already screwed I guess.

kentfredric commented May 10, 2015

This desire can only be rejected, it is unfulfillable. CPAN infrastructure is faster than you seem to believe. Every file you upload is squirreled away before anybody can click any delete button.

I don't mean that it will be "flawless", you will still of course need some other kind of ass-cover for everywhere else it replicates to.

Its just a "minimize damage" step. Though I guess if its already hit a primary mirror then you're already screwed I guess.

@oalders

This comment has been minimized.

Show comment
Hide comment
@oalders

oalders May 10, 2015

On a related note, once something is on CPAN, MetaCPAN doesn't have a good way of deleting things. metacpan/metacpan-api#359

oalders commented May 10, 2015

On a related note, once something is on CPAN, MetaCPAN doesn't have a good way of deleting things. metacpan/metacpan-api#359

@nigelhorne

This comment has been minimized.

Show comment
Hide comment
@nigelhorne

nigelhorne Oct 26, 2017

Agreed. This would help. See my recent post on modules@perl.org.

nigelhorne commented Oct 26, 2017

Agreed. This would help. See my recent post on modules@perl.org.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment