Happy to maintain/contribute for clj-commons/ring-buffer

[BrunoBonacci]

Hi,
I'm happy to carry on the maintenance of clj-commons/ring-buffer.
I use this library extensively in many of my own projects/libraries so I'm happy to
maintain it for the foreseeable future.

[slipset]

Hi Bruno,

That's great news. I've added you as a collaborator on that project. Please let me know if there is something that doesn't work out for you.

Erik.

[BrunoBonacci]

Hi @slipset,

thanks very much for adding me. Now there is a couple of things to clarify.

1. new releases should be published with a new maven/group-id or the original group-id?
   for example, if I cut a new release for ring-buffer and publish in the Clojars should this new release
   be amalloy/ring-buffer or clj-commons/ring-buffer? either way, I need access to the Clojars organizations/projects.
   This is probably something that we should clarify at the clj-commons organization level so that all the projects within this umbrella follow the same approach.

2. I think it would be better if the original github project would still exist with just a README.md
   which explains that the project has been moved here. This is useful for all the people who are searching for a project in the old location. Again, this should be written as a guideline for all the projects under clj-commons.
   @amalloy: could you please create a repo for ring-buffer in your github account and link the clj-commons/ring-buffer?

[danielcompton]

Hi @BrunoBonacci, it's weekend here for me, but I've discussed both of these with Alan, will update this tomorrow.

[danielcompton]

Hi @BrunoBonacci

I've added you to the CODEOWNERS file for ring-buffer.

1: new releases should be published with a new maven/group-id or the original group-id?

We've talked about this a bit on Slack in #clj-commons and I'm of the opinion that where possible, it is better to preserve the original Group ID. It keeps the continuity of the original project and makes it clear that CLJ Commons is a continuation of the original project. It also cuts down on the number of forks of a project which can be confusing to resolve. Switching to a different group ID means that people won't be able to detect new versions with tools like lein-ancient, and the download counts for the projects will be reset.

Where we can't get admin permissions on Clojars from the original author then forking the group ID to clj-commons seems like the best option.

Currently there is no way to delegate admin permissions in Clojars at the artifact level, only the group level. Alan's given me admin permissions to the org.flatland and amalloy groups which contains other things than just ring-buffer. Until we get the Clojars feature resolved, I'm happy to cut releases for these projects whenever you'd like?

2 I think it would be better if the original github project would still exist with just a README.md
which explains that the project has been moved here.

When Alan transferred the ring-buffer project from his GitHub account to the CLJ Commons organisation, GitHub added a redirect. Any links to https://github.com/amalloy/ring-buffer will automatically redirect to https://github.com/clj-commons/ring-buffer. I've also put some history at the bottom of the README to explain the change.

I agree on setting up some guidelines for maintaining these projects, I haven't had anywhere to put them yet as we're still working on the name for this project in #8. I did open a thread on CloureVerse with some of these questions, so you could add your thoughts/questions there for now if you like?

Thanks for coming on board to maintain ring-buffer, I really appreciate it.