Hi Rich, agree, it's what I bring to the thread multiple times (at least Brooklyn and Pulsar communities are willing to help, or find an alternative (fork or whatever)).
Regards JB On Mon, Feb 13, 2023 at 2:33 PM Rich Bowen <rbo...@apache.org> wrote: > > 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. > > > 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/ > >
