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/ >
