Please delete https://clojars.org/org.danielsz/system/versions/0.4.0-SNAPSHOT

[danielsz]

I meant to upload the release, forgot to remove the "SNAPSHOT" fragment.

Sorry :-(

[danielsz]

As requested, more info: defproject org.danielsz/system "0.4.0-SNAPSHOT"

Thank you.

[danielcompton]

Hi @danielsz

I've talked with @tobias about this and we're not going to remove the snapshot version. The Clojars repository aims to be as immutable as possible, modulo security issues or leaked credentials. Rich Hickey's recent talk (which you've probably seen) talks about the benefits of this: https://www.youtube.com/watch?v=oyLBGkS5ICk.

As far as I can tell, leaving the SNAPSHOT in Clojars doesn't negatively affect anything, so there is no reason to delete it. You're free to release 0.4.0 whenever you like though.

I don't quite understand why you want this SNAPSHOT deleted so strongly. Is there something I'm missing here?

[danielsz]

Yes, what you're missing is that this is not a call you can make for me. I didn't intend to publish this SNAPSHOT. It was a mistake! I would have undone it the moment I published it.

Please allow a timed window of opportunity to undo mistakes. This is not a breach in the overall immutability of the system. Not in any meaningful way. There is no race to fetch mistakenly published artefacts. This is a social system.
#616

[danielsz]

#616

[danielsz]

Yes, I have seen Hickey's talk. He talks about the ecosystem, I'm talking about the act of publishing.
Libraries should only accrue and not break, absolutely. This is different. This is about fixing a mistake when releasing a library. It is very cynical of you to utilize Rich Hickey's name in this context.

[danielcompton]

This has gotten far more heated than I wanted it to.

I didn't intend to use Rich as an argument from authority, he discusses Maven Central being immutable and not allowing changes here.

Clojars deletion policy is to not delete JARs unless there is a really compelling reason. Reasonable people could disagree over how strict our policy should be. However, I don't see how the current policy of not deleting a SNAPSHOT affects you negatively in any way.

[danielsz]

I agree with every word Rich Hickey makes in this talk, but rejecting my plea to delete a mistakenly published artifact on behalf of the ideas expounded therein is misguided. We all want an immutable repository. We also want to acknowledge that this is a social system. Humans do mistakes and there should be a possibility to fix common mistakes.

You have a stated policy that does not correspond to actual practice. #599 has nothing to with your policy, and yet you granted deletion. Same goes for #607. And this is by looking at the top of the list, and it a long list. It seems you are merely human too.

By denying me the right to fix my mistake, you are taking a right I have not granted you. You are punishing my fallible nature in the name of dogma. I object to this.

[tobias]

Our deletion policy boils down to trust. Just as we all trust library
developers to release library versions without bugs, we trust Clojars
to give us version X of a library when we ask for it, and for it to be
identical to the version X it gave us yesterday. And just like library
developers who make mistakes and introduce bugs, we Clojars
maintainers make mistakes and have sometimes honored delete requests
when we shouldn't have.

As developers, we understand that bugs happen, and are forgiving. But
if it happens enough times, that trust is destroyed, and we stop using
the library in question. For Clojars, every time we delete an
artifact, we are eroding the trust users have in us, so should
consider those deletions very carefully.

I've been talking about deletions in general, so let's talk about
system specifically. system is a fairly popular library; it's had
over 14k downloads, and is well known. It's possible that one of your
users has noticed the release and bumped their dependency, or have
their version set to "LATEST", which could have pulled the
SNAPSHOT. For the two deletion issues you cited, those were brand new
projects with no announcements or prior releases, so it was highly
unlikely they had any users.

Regardless, you are correct - we (mostly I) haven't been consistent with
enforcement of our deletion policy in the past,
but that has been a mistake. We've clarified the policy, and will
follow a much stricter adherence in the future. This doesn't preclude
a solution that may come out of #616 to deal with mistaken deployments
in the future.

[danielsz]

Well, since we are now talking in particulars, we know for a fact that no such trust would be eroded by deleting system-0.4.0-SNAPSHOT as it has 0 downloads. I am asking to delete it before it's too late. It was never meant to be, and I've alerted you about this at the same minute I've deployed it by mistake. By rejecting my request, you are putting me and my users at risk of trust erosion.
Also, it is odd that you should do that considering the numerous requests granted for the same reason.
A responsible approach would consist in granting this request and start thinking together on the challenging problem that has unraveled (and that we have started tackling in #616).

[tobias]

As I mentioned in #616 - we have no way to know if it has had zero downloads. And I understand that you filed this issue as soon as you realized the mistake, please understand that I have responsibilities that have a higher priority than my volunteer position with Clojars, so wasn't able to respond to your issue in a manner you considered timely.

WRT trust - it was my understanding that this SNAPSHOT is identical to the 0.4.0 release, is that not correct? If it is, how does that erode trust?

[danielsz]

My efforts with system are also outside of work, so we're all in the same business: volunteering.
I consider every user request that comes my way, sometimes I am forthcoming, sometimes less so. Not all requests can be granted. I understand that.

As a Clojars user, I have made a timely deletion request due to a mistake of my own doing that I was eager to undo. I discovered that this is a common problem due to the social nature of the beast. I mentioned the number 400 somewhat arbitrarily, but this is probably not too far off. Browsing the 424 closed issues, one cannot stop from noticing that the majority of them are deletion requests.

#508, for example, sounds awfully like mine: "I messed up and deployed a version that should not exist. Please delete [com.apa512/rethinkdb "1.14.4-SNAPSHOT"]." It was granted without fuss. Also a well known project with thousands of downloads.

Now you're asking me to internalize the idea that my request is being rejected on the basis of a sudden resurgence of strict policy adherence. What do you think happens to user trust in these circumstances?

As you have correctly pointed out, my users won't be adversely affected this time, because the stable release and the snapshot are identical. However, I feel this has grown into something else, something bigger, more challenging and ominous. How do you solve a social problem that technology alone cannot?

I am not advocating for more complexity à la Maven. I don't want a staging environment and delayed deployments. We all want an immutable repository that we can trust. But we also want to exercise reason and common sense while dealing with problems. We want to give users the ability to correct mistakes that are inevitable because users are human. We should not have to plead with you, hoping for a favorable verdict. Uncompromising policy compliance is not the answer, because you cannot enforce it (as the factual history indicates), and we cannot abide by it.

There must be something else.

[tobias]

After a blissful week away from the computer, I've had some time to
reflect on this.

First, I want to apologize for the the tone and firmmess of some of my
responses here - that was due in part to me rushing to attempt to wrap
this up before I left for the week, and in part a personal response to
your tone on twitter.

I've been giving deletions some thought for the last couple of months,
and had realized that being as free as we have been with deletions has
been a mistake, and your request came in during efforts to move us
toward tighter policy adherence. As I said, I've made mistakes, #508
possibly being one of them (almost a year ago).

I agree with you that this a people problem, and not a technical
one. I also agree that we should be willing to discuss deletions on a
case-by-case basis, and not blindly adhere to the policy. I was wrong
to imply we would adhere to it blindly. I also agree that this was an
important discussion to have, and I'm glad we're having it.

With regards to the circumstances around 0.4.0-SNAPSHOT (and similar
requests like #612), I still don't think they warrant manual deletion,
but are definitely good candidates for #616.

[danielcompton]

Just to add some background to #508, at the time, the most recent version would have been around 0.14.3. The 1.14.4-SNAPSHOT version implied that the major version had been bumped/was about to be bumped, and could have been confusing to people looking at the versions on Clojars, as there would have been this SNAPSHOT that had a very different version number to everything else that had been deleted.

I'm not saying that we should have deleted that one either, but the circumstances are a little bit different from the much more common pattern of deploying x.y.z-SNAPSHOT, then following up with x.y.z.

[danielsz]

That is wonderful to hear, @tobias, it looks like we've embarked on
a warm and fuzzy journey to reconciliation.

Please feel free to discard my deletion request. There's an extraneous
snapshot out there, but it is of no consequence. Nothing bad happened.

Thank you for keeping the discussion in #616 open, for it is one
we need to have.

A software repository caters to two classes of users: developers who
are pulling dependencies and a subset of authors who are deploying
those dependencies in the form of libraries.

This entails that preserving the integrity of the repository on behalf
of the developer community is one thing, while the other is providing
a publishing process that takes the authors' needs into account.

Authors like to stay in control. They have a sense of ownership over
their code. Authors may want to fix mistakes while publishing their
packages.

Reconciling the tension between the two imperatives is not always easy.

npm has unpublish, rubygems has yank, hackage has deprecate and
maven has a staging repository.

Clojars needs to craft an answer of its own, and I'm sure it will in time.

I'll be happy to contribute further down the road.