Forwarding with the jclouds users list address fixed
On Mon, Jan 30, 2023 at 10:15 AM Ignasi Barrera <n...@apache.org> wrote: > Hi! > > This is a call to action for everyone that expressed interest in helping > keep the project alive. > There has been a concrete request for help here: > https://lists.apache.org/thread/z7lg1y0rjp2xlkxhkkg76190tx2lznjt > > Who can take it? > > > > > > On Mon, Jan 30, 2023 at 6:26 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Fair enough. Thanks Andrew. >> >> Regards >> >> JB >> >> On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <g...@apache.org> wrote: >> > >> > Retiring the project to the attic is not my preferred outcome but I >> > think accurately captures the current state of affairs. Let's run a >> > final release then we can proceed with a formal discussion and vote. >> > >> > On Fri, Jan 13, 2023 at 08:44:27AM +0100, Jean-Baptiste Onofré wrote: >> > > 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/ >> > > > > > > >> > > > > >> > >> > -- >> > Andrew Gaul >> > http://gaul.org/ >> >
