Thank you for providing this additional context, and for your patience with an outsider swooping in with solutions. :)
I'll go read that thread and correct my misconceptions. It seems a great shame to have to either fork or reboot a project, when one is there, but I am glad to hear that you're already investigating options. --Rich On 2023/02/13 14:01:11 Ignasi Barrera wrote: > FWIW, this is the complete discussion: > https://lists.apache.org/thread/w61gzk2ohjtshbwcb5gy6wb2htv7fo0x > > It was actually cross-posted to the Brooklyn dev list [1] and some of > the PMC members there expressed their opinion. > > We are, however, somehow blocked by inaction and I honestly don't know > what would be the best way to move forward: > > On one hand, we'd love to have jclouds around and avoid moving it to the > attic. > On the other hand, though, we feel we must be responsible to the > community and properly set expectations and reflect the project > reality, retiring it if there is no real energy/time to continue it. > This thread is several months old now, and nothing has changed. We did > several calls to action with concrete requests for help, but no > further engagement happened. > > I know we all have the best intentions here when willing to keep > jclouds alive, but after several failed requests for help to those > that want to keep the project alive, and several months of waiting and > going in circles... > Are we doing the right thing for the community by changing the current > jclouds project PMC with another inactive PMC? (And if anyone thinks > the new PMC wouldn't be inactive... why has no one taken any action in > all these months?). > > > > > My 0.02$ > > I. > > > > [1] https://lists.apache.org/thread/6o20d0w1f1xroyo4vv33hlvyb1lk4ndd > > On Mon, Feb 13, 2023 at 2:54 PM Enrico Olivelli <eolive...@gmail.com> wrote: > > > > Il giorno lun 13 feb 2023 alle ore 14:33 Rich Bowen > > <rbo...@apache.org> ha scritto: > > > > > > Please talk with the Brooklyn folks before taking this step. In their > > > February board report they indicate that jclouds is one of their main > > > dependencies, and if you move to the attic, they would be compelled to > > > either find an alternative or reboot (or fork) the project. This > > > indicates, at least to me, that there are people in that project have > > > both the expertise and incentive to keep this project alive. As such, it > > > would be wise to reach out to them, and see whether any of them can > > > augment the project to keep it alive, or possibly some other solution. > > > But please don't take this step without at least speaking to them. Thanks. > > > > I would also add that Apache Pulsar is using JClouds and we (Pulsar > > PMC) would be needed to fork or to move to the Brooklyn fork in case > > that the projects moves there > > > > Enrico > > > > > > > > > > > On 2023/01/29 08:07:48 Andrew Gaul 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/ > > > > >