On Sun, Dec 11, 2022 at 03:25:04PM +0000, Geoff Macartney wrote: > Can we try to get some data on what amount of effort is required here? > Andrew, Ignasi, here are some questions for you. > > If we want to at least keep Jclouds going, without necessarily doing much > fresh feature development on it: > > 1. What do you think is a desirable *minimum* number of active contributors > to the project (doing releases, dependency updates, security fixes, > occasional important bug fixes)?
Apache projects need a quorum of 3 committers to make a release which jclouds will soon lack. Mechanically, a single motivated person could keep pushing releases with a few drive-by +1s. But practically, the jclouds blobstore and compute scope is large enough that two people should maintain the project with some domain expertise. > 2. How much work is that likely to involve? (Approx time commitment). Let's > separate out how much effort it is to build, test and publish a release > from other stuff which is going to be more ad-hoc. I estimate that I spend 10 hours per release: * triaging blobstore issues (~1 hour) * reviewing/pushing forward outstanding PRs (~2 hours) * running integration tests (~1 hour) * dealing with jclouds tech debt and breakages (0-10 hours?) * Apache process and overhead (~1 hour) * fixes that help my project or look easy (? hours) > 3. How much access to cloud providers/infrastructure is required to test a > release? How expensive is it? I have access to all the major blobstore providers and run integration tests for them. I estimate this costs me less than $1 but running compute tests may cost more. Note that there are flaky and broken tests which require some judgment call so I only look at the diff between releases. > 4. How much work would it be for new contributors to learn the codebase > well enough to contribute effectively? jclouds is a big project that uses a custom annotation mechanism (RestAnnotationProcessor) and extensively (excessively?) uses Guice which makes it hard for many people (including me!) to understand. We could debate the merits of the technical approach but socially this makes it hard to attract contributors. I also think that the technical debt that jclouds has accrued generally makes it less pleasant to work on than simpler or newer projects. I don't think this answers your question but Ignasi and I now work outside the Java and cloud ecosystems and are not in a good position to explain/rediscover how this all works. > I think if we know better how much it will take, we can each more easily > ask ourselves, "could I do this"? If enough of us say "yes", we may avoid > the attic yet. I don't know that avoiding the attic should be the goal. If there are motivated people that want to continue jclouds then please do so. But currently no one is doing any work towards this end. jclouds continues to accrue technical debt (e.g., gson 2.9.0 incompatibility) and there is no one left to do this work. I think it would be good for a new contributor to step back and compare against similar multi-cloud projects like libcloud to evaluate what jclouds does well and what it does not. I suspect that reimplementing the REST APIs is not a good choice in 2022 and instead jclouds or a similar library should reuse the vendor SDKs and focus only on multi-cloud portability. And simplify the project so users can become contributors more easily. -- Andrew Gaul http://gaul.org/
