New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future home/support for Shadow? #908
Comments
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:
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? |
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. |
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:
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:
Please feel free to share your thoughts. I'd like to get a consensus and make a decision soon.
The text was updated successfully, but these errors were encountered: