Replies: 19 comments 2 replies
-
I've talked with Toby and while I understand where you're coming from, allowing users to make deletions isn't a goal for Clojars. Our aim is to provide an immutable and stable repository. Clojars was created in part as a reaction to Maven Central requiring deploys to be manually promoted to the repository after being released at the command line. If the ability to tightly control which versions of your software are released, and to prevent accidental deploys, then you could look at publishing through Maven Central, as it has the controls you're looking for. It would make no difference to your consumers as all Clojure tooling has Clojars and Maven Central loaded. |
Beta Was this translation helpful? Give feedback.
-
You have granted 400 deletions requests. Its all there in the issues. What are you even talking about? |
Beta Was this translation helpful? Give feedback.
-
It's unclear where you are getting the 400 deletions number from, but There are a few ways to implement what you are asking:
I have a few concerns about this approach:
Concerns here are:
Concerns here are:
Please keep in mind that Clojars is maintained by volunteers, so any |
Beta Was this translation helpful? Give feedback.
-
An alternative to deletions, that would help prevent accidental deploys, without affecting the immutability of the repo is to provide a dry run option for |
Beta Was this translation helpful? Give feedback.
-
I suppose it might be worth considering why people want to delete deployments. If they accidentally embedded passwords/creds then having a way to allow users delete their own in such an emergency might be valuable but I don't think that is very common. Do we know why most deletions are requested? If not we might want to ask. One possible way to do this is having the existing "delete me" trigger an automated delete. Given that redeploying requires authentication this would be secure. It only eliminates the manual step (no UI changes, etc) |
Beta Was this translation helpful? Give feedback.
-
@tobias What consitutes a good age? This is a good question. 1 minute is certainly a good age. Maybe 10 minutes is reasonable too. Within that window of opportunity, authors are granted full permissions to delete the artefact in the same way that deployment was granted. This is in line with @kahunamoore's suggestion. This would take care of many deletion requests, and yes, there will always be those cases that fall outside of the granted scope, and then you will need to resort to the current deletion requests/approval/rejection ballet that takes place in the issues. But those will be dramatically reduced. Win win situation for both users and admins. All this without impacting the immutable nature of the repository. |
Beta Was this translation helpful? Give feedback.
-
@tobias An alternative to the timed window of opportunity would be a check on the number of downloads. As long as that number is zero, it is safe to delete. Nobody is using it yet. My snapshot version that I asked to delete currently has 0 downloads. If this number changes, upon whose shoulders would the responsibility rest in your opinion? |
Beta Was this translation helpful? Give feedback.
-
Please take my comments with a grain of salt. I'm not a maintainer and don't have the history/knowledge of Clojars like others do. Also, congratulations on getting into SFC! Way to go... thank for all your hard work. |
Beta Was this translation helpful? Give feedback.
-
1 to checking download count & if zero, allowing deletions. |
Beta Was this translation helpful? Give feedback.
-
The most common cause of deletions that we have performed in the past have been private code and/or credentials being published, and those generally come through email. Of those, I'd say less than half have been out for a while (days to months) before the issue was discovered, so a cooling off period wouldn't help with those. Using the description contents as a trigger is an interesting idea, but wouldn't work - say you push 0.3.0, and realize you want it (and not the entire project) deleted. You can't push to 0.3.0 again, so would need to push an 0.3.1 (or whatever), and we'd have no way to know you want 0.3.0 0.3.1 deleted. And thanks for the kind words :) I would only be comfortable with an age period if there were a staging repository. We can say that it's unlikely that a user will download the release within that period, but we can't guarantee that. WRT the download count: we can't see the download count for today, only yesterday and before. This is because we only process logs once a day, which includes the nginx log and several hundred logs from our CDN provider, so looking at downloads isn't a viable option. I'm open to a solution for this, but will likely need someone in the community to drive the implementation - I don't have a lot of time to devote to Clojars currently. |
Beta Was this translation helpful? Give feedback.
-
Not to be flip, but why not just deploy a new version that fixes whatever was in the broken one? This happened to me in the past and that seemed like the obvious way to "fix" it. My presumption is that deletes create a lot of implementation and policy complexity and it doesn't seem worth that in comparison to the frequency or severity of occurrence. The Maven Central staging model is a pain and certainly everything we deploy for Clojure and contrib is done in an automated way such that it creates the identical problem, so I don't see staging as any improvement. |
Beta Was this translation helpful? Give feedback.
-
@puredanger I'm not sure how the suggestion to "just deploy a new one" would fix the case that spawned this issue: the 'defect' was in the version identifier itself (namely the accidental inclusion of "SNAPSHOT" when it was not intended to be a SNAPSHOT). |
Beta Was this translation helpful? Give feedback.
-
I agree that releasing X.Y.Z after releasing X.Y.Z-SNAPSHOT is strange, however, since they would both contain identical code, the SNAPSHOT semantics would still be maintained (i.e., SNAPSHOT is >= the non-SNAPSHOT in terms of functionality/api surface area/etc). |
Beta Was this translation helpful? Give feedback.
-
@puredanger @johanatan Correct, there is no danger of shipping broken code. But I believe we should examine other avenues when dealing with accidental deployments. Some thoughts in #615, |
Beta Was this translation helpful? Give feedback.
-
Just another data point: npm made some changes for unpublishing after last year's leftpad fiasco. http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
|
Beta Was this translation helpful? Give feedback.
-
@johanatan Releasing X.Y.Z after X.Y.Z-SNAPSHOT is the proper practice, and not strange at all. The snapshots lead up to the actual release, not vice-versa. |
Beta Was this translation helpful? Give feedback.
-
Is it possible to exclude DEPRECIATED artefacts from search? Or at least show them AFTER the non depreciated artefacts. We have reorganized our artefact system, and want to make sure that users do not get confused and by mistake use old versions. It is not very helpful, if the first couple of pages only show depreciated projects. |
Beta Was this translation helpful? Give feedback.
-
Five years and a number of world-changing events later... thread necromancy time! Did anything interesting happen apropos this topic? I found myself scrambling in the wee hours earlier today, having goofed on the packaging of an artifact - missed a piece after having converted a project to use a git submodule - to deploy a fixed artifact, after having issued |
Beta Was this translation helpful? Give feedback.
-
Please allow authors to delete artefacts just after publishing. The exact amount of time during which they are allowed to do that doesn't matter. The principle does.
Mistakes will happen. This sentence comes in many flavors, as it is such an essential trait in humans. Currently, Clojars doesn't allow authors to undo their mistakes.
This is not a breach in the overall immutability of the system. Not in any meaningful way. There is no race to fetch a mistakenly published artefact. If it was up to me, nobody would have time to. I realized my mistake the second I published it.
Also, it looks like this would take care of many of the pleads for deletion people resort to as a desperate measure.
Thank you for listening.
Beta Was this translation helpful? Give feedback.
All reactions