all repos in the aleph-io organization

[ztellman]

I recently moved all projects related to Aleph into a separate org so I could give @kachayev full access to the repos. Unfortunately, neither of us are doing much Clojure development these days, so putting them into the hands of clj-commons seems like the best path forward at this point.

I've had the goal for the last few years to cut a 1.0 release of all these projects, and let them potentially be in maintenance mode (targeting the latest Netty point releases as necessary, little else), but even in that case there would need to be some support for people reporting stability issues, etc (it's usually an error on their part, but that's not a given and the nature of the error isn't always obvious).

Happy to provide more context as needed, but hopefully this is enough information to start the conversation.

[slipset]

Hi Zach,

I'll be frank and say I'm somewhere right in the middle between flattered and scared shitless about this proposal.
So here's some of my thinking: Of the projects in aleph-io, it seems like aleph and manifold are the two big ones. I'd imagine potemkin should more or less be done and is thus in maintenance mode. That could be stated in the Readme. I guess the same could be said for byte-streams and byte-transforms as well, although the two latter might need somewhat more active maintenance?

This leaves us with the two, big scary ones, aleph and manifold. Having had a cursory glance through both of them, it seems like aleph is the scariest. I guess that with some backchannel advice or such from you, we should be able to keep both of them on life-support until new, dedicated, maintainers step up, but I don't think we can promise to do much more than, as you said, follow the point-releases of netty for aleph.

As for more practical problems, you either need to give clojars access to me (and possibly others) so that we can publish new versions of the libs, or we need to give them a new name (clj-commons/aleph etc comes to mind).

How does this sound to you?

[borkdude]

@slipset Maybe we could ask some major companies using Aleph (via Yada, like JUXT (cc @malcolmsparks) or via the list here: clj-commons/aleph#450) if there are people that have intimate knowledge of Aleph that are willing to help out as maintainers on clj-commons?

I think maintenance works best if people have some sense of ownership or responsibility. Maybe this is something to think about for clj-commons. It's great that libs are here so at least they can be maintained if necessary. So far it feels like libs are being brought in while nobody really "owns" them. I could be wrong about this.

[lread]

Yeah I'm sure finding committed maintainers is a challenge.

I've taken on stewardship of rewrite-cljc (a successor the the now unmaintained rewrite-clj and rewrite-cljs). I fully plan to move this to clj-commons once it is alpha-ready (and will gladly accept @borkdude's offer of comaintainer). Given that I am a curious fellow and highly distractable, even though I am committed, my progress has been slow. Because this is unpaid hobby work for me, and I like it that way, I don't know of an impetus that would make me move quicker.

That said, I do feel a sense of ownership and responsibility for rewrite-cljc.

Perhaps some sort of categorization for clj-commons projects might help? Projects might be:

• actively maintained - there might not be any recent commits because the library is effectively complete, but someone has taken on a stewardship role.
• looking for a maintainer
• archived for historical purposes - this might be true for a project like rewrite-cljs

In the rewrite-cljc README I have a current maintainers section. Perhaps this would be good to add to all clj-commons projects?

It is almost like an active role of recruiter is needed to find, and maybe retain, maintainers. It would just need someone who finds meaning and/or joy in this role.

[KingMob]

I adopted the aleph/manifold stack recently, and am willing to help out. I think I know byte-streams and manifold well enough to maintain, if nobody else is interested in stepping up. I definitely don't know Aleph+Netty that well yet, though.

[valerauko]

I'm willing and able to help! I won't claim I understand the executor implementation under manifold/Dirigiste, but I can deal with Netty stuff (including exposing http/2). We use aleph in production too.

[tanzoniteblack]

I've been maintaining a fork of manifold for use at Yummly since April that has a number of fixes to let-flow ( changelog ) & a new helper called tsasvla to give a core.async/go macro variant with more flexibility in the concurrency then let-flow ( see motivation here ). At this point, I'm fairly familiar with a lot of the internals of manifold & would be happy to help maintain it.

Don't have much experience with the internals of any of the other libraries under the aleph-io org.

N.B. We forked because the project seemed dead, wasn't getting any new releases, and we really needed a bug fix for our scale ( clj-commons/manifold#160 )

[frap]

I can help on maintaining. Use libs a bit but no expert - but keen to help

[abhishekamralkar]

I am interested in maintaining it. Not an expert on Clojure but used Aleph for Clojure application and I am on and off on Clojure. Now mostly using Clojure for some of my hobby projects.

[solatis]

I’ll be more than happy to help with Manifold. The surface area for aleph is a bit too much for me to handle, but I’ve used Manifold for years, advocate for it whenever I get the chance, am very much aware of its inner workings, and am more than happy to lead this effort and/or help out.

Dirigeste comes as a part of this, more than happy to take on this as well.

[ztellman]

Thanks so much to everyone who responded. The clj-commons folk have expressed a bit of concern that these repos will be something of a white elephant, given the scope of the projects (to say nothing of the issue backlogs). I want to clarify that my hope is that the clj-commons teams will be mostly responsible for continuity, while the actual work will be done by other volunteers, who will inevitably come and go over time. If no one steps up as a lead maintainer for a project, they might be responsible for cutting releases, and adjudicating any disagreements over project direction. Otherwise, they'd simply be responsible for appointing lead maintainers, and keeping those maintainers honest about whether it's time to hand the reins off to someone else (as I should have done years ago).

Does that sound reasonable to everyone?

[slipset]

This sounds perfectly reasonable, and I think this is a good way forward for other projects of similar size. clj-commons ensures the continuity while appointed maintainers move the projects forward.

In this case I hope you @ztellman would be able to serve as some sort of advisor as to whom to pick as maintainer.

[KingMob]

@ztellman That sounds good to me.

[slipset]

@ztellman I've invited you to the clj-commons org, so all you need to do now is to accept the invitation and transfer the repos.

[ztellman]

I've transferred over the repos, I'll follow up within the next few days with some thoughts on how to onboard new contributors.

[slipset]

Thank you. Also, we need to think about deployment of artefacts. Should they continue to be deployed to clojars under current coordinates, or should they be moved under the clj-commons group-id. The former requires you to give access to new maintainers to publish artefacts, the latter means a change in group-id.

[greglook]

I'd also be happy to help maintain these projects. I understand manifold pretty deeply, aleph less so. We use both at Amperity so we're very motivated to keep them going!

[danielcompton]

Should they continue to be deployed to clojars under current coordinates, or should they be moved under the clj-commons group-id. The former requires you to give access to new maintainers to publish artefacts, the latter means a change in group-id.

Given that the projects are under their own groupID's which don't conflict with anything else @ztellman owns, I'd recommend keeping the group ID's the same for now so that the lineage is clear, and upgraders get notified about new versions.

@ztellman if you're happy with that, can you add erik and danielcompton as admins of the groups in Clojars so we can manage future releases?

[slipset]

A thing to consider is, if I understand it correctly, the deps.edn push towards nudging lobs to have group ids, but I guess libs without group ids have an implicit group which is their artefact id?

[danielcompton]

libs without group ids have an implicit group which is their artefact id?

Yeah, Leiningen (and up until recently deps.edn) allowed you to write aleph as a dependency and it would expand it to aleph/aleph (group ID aleph/artifact ID aleph).

[ztellman]

I think all of my projects are a bit out of sync with the (totally reasonable) new norm in Clojure that each project shouldn't have its own organization. The three options I see are:

• Leave them where they are, and set up a Clojars deploy key for all of them
• Move them all under the io.aleph organization, which is a domain I'm happy to own and maintain indefinitely
• Move them under the clj-commons organization

I think the last two are better than the first, but I'm pretty indifferent as to which we choose.

[slipset]

Then I'd vote for moving them under clj-commons, if only for convenience and branding reasons?

[danielcompton]

I'm a weak +1 on cli-commons. I'd slightly prefer to keep them where they are for now as there isn't a good story for upgrade notifications when you change the group ID, but happy to defer to @slipset who has been the most active on this.

[ztellman]

I've opened a new issue to track the overall milestone of release v1.0, which I think will require us onboarding many or all of the people who have commented in this thread: clj-commons/aleph#555. I'm fine with just releasing everything under clj-commons, fwiw.

[slipset]

Closing this as we've moved everything,