Future home/support for Shadow?
johnrengelman opened this issue · 20 comments
This project started 12 years ago (eb773b1) as a way for me to address CI/CD tooling for developer teams when I was consulting. It has had a long run and I'm glad that the community has enjoyed the capabilities that it brings.
But as many of you have noticed, I have not had as much time to manage this project over the last few years. There's a few big points that I'd like to call out:
- I believe that shadow is feature complete and any additional capabilities should be added as extensions or wrappers to Shadow. I could see some future development to make Shadow more generic with plugins to enable this, but IMO, shadow shouldn't be bloated with a bunch of different features.
- Shadows place in the ecosystem is directly impacted by the more rapid development and releases in both Java and Gradle and so this project has become mostly responding to those changes...particularly Gradle changes since Shadow relies on some internal APIs of Gradle.
- There is an opportunity to influence the Gradle team to expose more public API or structures that would make Shadow simpler, but that will require some significant time investment to work through their processes.
- Over the last decade my career trajectory has changed sufficiently that I can't reasonably argue that working on Shadow is related to my job, so that puts it has a night/weekend hobby where I'd prefer to dedicate more time to my family.
With all that said, it's time for Shadow to find either a new home or a new set of maintainers that I can turn the keys over to. @Goooler has been doing a wonderful job lately and is supporting users with their fork. I see a few options that are viable:
- Keep the plugin here and add additional maintainers that can commit and release
- Move to @Goooler's fork and deprecate this plugin
- Identify a foundation/community model that would take the plugin with multiple maintainers (I bring this up in case there is strong feeling to get individual's names out of the plugin id).
Please feel free to share your thoughts. I'd like to get a consensus and make a decision soon.
The thrid would be great.
Thank you for all the work you've put into this project over the years! I don't have strong feelings but I also prefer option 3 if that's viable. At least at CashApp we use this project widely in our internal builds and plan to continue to do so with newer versions of Gradle. As long as I'm working in my current capacity I'm happy to try to contribute fixes and patches that serve that goal.
Hello @johnrengelman. From my side (Gradle community manager), I am interested in building a community hub and community-governed GitHub organization that would offer a home for plugin and other key components maintainers who want to ensure continuity of the plugins. I call it Project Gradliverse (inspired by Quarkus), but this is not a finalized name.
From GitHub perspective it would be an org that offers hosting, various automations to simplify the life of maintainers (CI/CD, release flow, changelogs, docs hosting, etc.), encourages the best practices for plugin development, and also clear governance model that offers the maintainers almost full powers but defines a process of transition should the maintainer want to move one or become inactive. It is somehow aligned with how Jenkins governance is defined and how we support maintainers
I have not yet published the proposal, but I am discussing it with the community members. I hope to go live soon, and I think the Shadow Plugin could be one of the pilot projects moving there
IMHO, the features of this plugin should be absorbed into native Gradle features, the same way unbroken-dome test-sets was (finally!) subsumed by native JVM Test Suites. Similarly, https://github.com/ben-manes/gradle-versions-plugin should be absorbed into Gradle. Both shadow and ben-manes are super-important, both depend on internal Gradle features and could be made to work better/faster if they were in Gradle's codebase, both started as "weekend projects", and both eventually fatigued the original authors.
Does anyone know how to start a conversation with the Gradle org about this?
Hi @jimshowalter @Goooler @martinbonnin
While I finalize the gradle/community#15 proposal and the approvals, I would suggest the following temporary solution:
- We transfer the repository to https://github.com/GradleUp, one of the popular GitHub organizations hosting a number of Gradle tools. I confirmed with @martinbonnin that he is open to it. CC @deepy too
- We synchronize changes by @Goooler to the new upstream, and I guess he becomes a maintainer of the repository
- Until gradle/community#15 is finalized, we do not change artifact/group IDs, but then we do something about it to unify for such a community hub recommendations we define
WDYT?
@oleg-nenashev The general outline above sounds promising. I think moving to https://github.com/GradleUp has a middle ground might be unnecessary though. I could add @Goooler as a collaborator to this repository and to the circle ci project and I believe you all could add portal access for him to publish plugin versions?
I could add @Goooler as a collaborator to this repository and to the circle ci project and I believe you all could add portal access for him to publish plugin versions?
Yes, this is possible.
I strongly believe that moving this project to some kind of organization with at least one other admin (whether one created by you or someone else) is necessary to avoid running into the same issue again. Having only a single person with administrative permissions on such a widely used tool is the most common factor for the entire project disappearing or breaking up into vaguely promoted forks while people using it scramble on how to go forward with the dependency
At the same time and with the same line of thought, I agree with jimshowalter that I would like to see features like relocation and easy exclusion/inclusion in Gradle-proper, or at least in an officially supported plugin. A community hub for gradle plugins with shadow would be the next best thing to that, including governance of even more trusted community leaders, as long as the bus factor doesn't stay at one or below
I'm finishing the proposal for Gradliverse, so it should move forward in a few weeks. I will be happy to publicize the version once I have a first review and green light.
@Goooler in the meantime, do you need any help from me to do the next release with your changes?
Yes, please.
Hello,
any update on this?
@johnrengelman, I just wanted to say thanks for all the hard work on this, this plugin is a must-have in most of my Gradle projects 🚀
I am ready to move forward on my side. Sorry for the long silence period; I was involved in getting the approvals for transfer and clarifying the process for mission-critical components. @Goooler we are ready to hand over permissions on the plugin portal to the previous plugin ID
@Goooler FYI, I will be off for the next month, but somebody from the team might be able to help if you are still interested. @ljacomet can help with the permissions updates
FWIW, gradle/community#15 is stuck pending internal approvals, and I do not have any ETA, so for now, the only actionable approach is @johnrengelman granting permissions as it was discussed before.
Thanks!
So, for the transfer we need:
- @johnrengelman to add @Goooler as a collaborator
- Do the permission transfer. https://github.com/gradle/plugin-portal-requests is needed for that
@Goooler what do you think? Should we create a new org, move the repo under that?
Do we want to keep using the same plugin id or start with a new one?
Both options LGTM at this stage. If the new org includes "Gradle" in it's name, I will take care of the trademark grant when I am black from vacation