Hi Geoff, To Geoff and others, happy new year :)
Yes, I agree: it seems the bandwidth is limited. So, I think it makes sense to move jclouds into attic; and let other projects find an alternative (forking part of jclouds, finding a brand new alternative, ...). Regards JB On Thu, Jan 12, 2023 at 6:28 PM Geoff Macartney <geom...@apache.org> wrote: > > Hi JB > > It appears that we don't have the collective bandwidth to add new active > contributors to the project, so, sadly, moving jclouds to the attic does > seem to be the right thing to do. It will be up to each downstream project > to figure out what it wants to do in consequence. > > Belated Happy New Year to all. > > Regards > Geoff > > > > On Thu, 29 Dec 2022 at 05:38, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > > Hi, > > > > Sorry to have been quiet, I'm "half off" for festive time ;) > > > > I'm still interested in helping maintain jclouds from a community > > standpoint. However, clearly, the current committers/PMC members don't > > want to be involved anymore. > > > > As most of the volunteers are not jclouds PMC members (I think I'm the > > only one), you have to accept the decision from PMC members. > > > > So, I see only three options for the projects using jclouds: > > 1. current PMC members accept to extend/expand the committer list (and > > PMC) to have new people volunteer to maintain jclouds, so projects can > > still use jclouds. I don't want to be pushy in this direction. It's > > important to have the long time PMC members, if they want to move > > jclouds in the attic, it's fair and we have to accept that. > > 2. replace jclouds with something else. That's probably the preferred > > approach, replacing jclouds directly with cloud providers APIs. > > 3. fork jclouds (or part of jclouds) in other projects (the part > > actually used in the project). For instance, we can imagine having > > code from jclouds moved/forked in brooklyn. > > > > My prefered option is probably 2, according to the discussion in this > > thread. > > > > Happy new year to all, > > Regards > > JB > > > > On Wed, Dec 28, 2022 at 9:11 PM Geoff Macartney <geom...@apache.org> > > wrote: > > > > > > Hi all, > > > > > > Hope you had a restful Christmas break. > > > > > > Andrew, thanks very much for these details, that is helpful to scope the > > > effort required to maintain jclouds. Of course what takes 10 hours for > > > Andrew, with his familiarity with jclouds, will take perhaps > > significantly > > > longer for those of us who are not yet familiar, even after an initial > > > period of learning. You'll each have your own estimations I'm sure. > > > > > > So - two questions to everyone who has expressed an interest in this > > > discussion (have I missed anyone?): > > > > > > Alex, Andrey, Enrico, Francois, JB, Juan, Iuliana, and anyone else for > > that > > > matter who hasn't yet spoken up. > > > > > > 1. Who among us feels strongly enough about their need for jclouds to > > > continue business as usual that they want to volunteer to commit to the > > > time it will take to learn it and then maintain it going forward > > (becoming > > > a committer)? This would not only include releases, as Andrew outlined, > > but > > > also security fixes, and maintenance as dependencies age (e.g. that gson > > > problem). It seems to me we need *at least* two volunteers for jclouds to > > > continue; three would be better. > > > > > > 2. Or do you agree with Andrew that avoiding the attic doesn't need to be > > > the goal? That everything has a natural lifetime and maybe the attic is > > now > > > the right course for jclouds? Perhaps you feel your effort would be > > better > > > directed toward adapting your own code to a world without jclouds. E.g. > > > from a Brooklyn point of view maybe the time is near for replacing > > > JCloudLocation with provider specific locations, or a new abstraction. > > Who > > > knows, that might even remove a slew of dependencies and assist us moving > > > on from Java 8. > > > > > > Concretely: if you want to volunteer to commit to maintaining jclouds, > > can > > > I ask you please to reply to this email to say so. > > > > > > Kind regards to all, and wishing you a Happy New Year. > > > > > > Geoff > > > > > > > > > > > > > > > On Sun, 25 Dec 2022 at 01:12, Andrew Gaul <g...@apache.org> wrote: > > > > > > > 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/ > > > > > >
