Re: move jclouds to the attic?

[Geoff Macartney <ge...@apache.org>]

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é <jb...@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 <ge...@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 <ga...@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/
> > >
>

Re: move jclouds to the attic?

[John Calcote <jo...@gmail.com>]

I wish someone would just say what needs to be said and be done with it.
That is, the project requires maintenance and leadership and no one wants
to take on that responsibility. Andrew is unwilling to continue
(essentially) alone, and who could blame him for it? He's asked several
people over the last few years to commit to fixing one issue or another -
including myself - and (like myself) most of those he's asked have simply
not had the time or desire to contribute at that level. We all have
excuses, including, "my day job is already a full time effort" (whose job
is not a full time effort these days?)

I love open source - and I hate it. It requires passion and effort in a
world that's too busy to allow anyone that kind of time and energy. I,
myself, am the sole remaining contributor to and maintainer of an open
source project - OpenSLP - and even though the code base is found in every
printer firmware in the world, and installed, by default, on many Linux
distributions, not one of these many consumers is interested in
contributing to it. I have plenty of requests (for me) to make
modifications and fix bugs, but very few patch offerings. I'll admit, the
project has languished over the years because I'm tired of being a sole
proprietorship in a service designed to be run by a community.

Let's get our heads straight about this - if we don't want to give, then we
can't expect to get in this arena. We've had plenty of emails from other
project contributors indicating that they'd have to fork if jclouds move to
the attic. Well, if you have to fork, then you'd have to maintain. Why not
help maintain it over here instead of over there? I'm guessing it's because
you're hoping it won't come to that.

John

On Mon, Feb 13, 2023 at 7:16 AM Rich Bowen <rb...@apache.org> wrote:

> 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 <eo...@gmail.com>
> wrote:
> > >
> > > Il giorno lun 13 feb 2023 alle ore 14:33 Rich Bowen
> > > <rb...@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 <
> geomacy@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é <
> jb@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 <
> geomacy@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 <ga...@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/
> > > > >
> >
>

Re: move jclouds to the attic?

[Rich Bowen <rb...@apache.org>]

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 <eo...@gmail.com> wrote:
> >
> > Il giorno lun 13 feb 2023 alle ore 14:33 Rich Bowen
> > <rb...@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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> > > >
> 

Re: move jclouds to the attic?

[Ignasi Barrera <na...@apache.org>]

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 <eo...@gmail.com> wrote:
>
> Il giorno lun 13 feb 2023 alle ore 14:33 Rich Bowen
> <rb...@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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> > >

Re: move jclouds to the attic?

[Enrico Olivelli <eo...@gmail.com>]

Il giorno lun 13 feb 2023 alle ore 14:33 Rich Bowen
<rb...@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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> >

Re: move jclouds to the attic?

[Geoff Macartney <ge...@gmail.com>]

Hi Rich,

Just to chip in my two cents' worth, we in Apache Brooklyn have been
involved in the discussions, and have tried to see if people can be found
to help continue jclouds. The eventual outcome of all the discussion,
however, seems to be that the attic is, sadly, the most realistic option
for the project at this point.

Ignasi, just on the point of

> We did several calls to action with concrete requests for help, but
no further engagement happened.

I don't think that's quite fair - numerous people both from Brooklyn and
other projects engaged with the discussions. What hasn't happened is people
stepping up to commit the necessary time to maintain and forward-develop
the project. To which point, John, on the point of

> We all have excuses, including, "my day job is already a full time
effort"

I think people are just being honest here, not making excuses.  As you say,
maintaining an open source project is a significant commitment,
especially on the scale of jclouds. I can speak only for myself I guess, so
to recap what I said earlier, I did really think about making the
commitment to start contributing to jclouds development and releases, but I
feel that if I did so I would just be kidding myself and everyone else. I
don't want to do that. I imagine others feel similarly.

As regards

> We've had plenty of emails from other project contributors indicating
that they'd have to fork if jclouds move to the attic.

It's not clear right now to us in Brooklyn what the implications of the
change are. Forking (part of?) jclouds would be one option, but as you say,
if we want to do that, why not just maintain the project?  However, I'm not
sure it is the likeliest of options. There are other possibilities, such as
implementing a minimal subset of jclouds-like functionality within
Brooklyn, just to cover our main use-cases. Other more radical options
might even involve changing the Brooklyn model to an extent. Right now it's
not clear. I have been meaning to kick off that discussion on
dev@brooklyn.a.o and this has prompted me again.

Regards to all,

Geoff








On Mon, 13 Feb 2023 at 17:17, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> 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 <rb...@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 <ge...@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é <
> jb@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 <
> geomacy@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 <ga...@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/
> > >
>

Re: move jclouds to the attic?

[Geoff Macartney <ge...@gmail.com>]

Hi Rich,

Just to chip in my two cents' worth, we in Apache Brooklyn have been
involved in the discussions, and have tried to see if people can be found
to help continue jclouds. The eventual outcome of all the discussion,
however, seems to be that the attic is, sadly, the most realistic option
for the project at this point.

Ignasi, just on the point of

> We did several calls to action with concrete requests for help, but
no further engagement happened.

I don't think that's quite fair - numerous people both from Brooklyn and
other projects engaged with the discussions. What hasn't happened is people
stepping up to commit the necessary time to maintain and forward-develop
the project. To which point, John, on the point of

> We all have excuses, including, "my day job is already a full time
effort"

I think people are just being honest here, not making excuses.  As you say,
maintaining an open source project is a significant commitment,
especially on the scale of jclouds. I can speak only for myself I guess, so
to recap what I said earlier, I did really think about making the
commitment to start contributing to jclouds development and releases, but I
feel that if I did so I would just be kidding myself and everyone else. I
don't want to do that. I imagine others feel similarly.

As regards

> We've had plenty of emails from other project contributors indicating
that they'd have to fork if jclouds move to the attic.

It's not clear right now to us in Brooklyn what the implications of the
change are. Forking (part of?) jclouds would be one option, but as you say,
if we want to do that, why not just maintain the project?  However, I'm not
sure it is the likeliest of options. There are other possibilities, such as
implementing a minimal subset of jclouds-like functionality within
Brooklyn, just to cover our main use-cases. Other more radical options
might even involve changing the Brooklyn model to an extent. Right now it's
not clear. I have been meaning to kick off that discussion on
dev@brooklyn.a.o and this has prompted me again.

Regards to all,

Geoff








On Mon, 13 Feb 2023 at 17:17, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> 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 <rb...@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 <ge...@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é <
> jb@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 <
> geomacy@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 <ga...@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/
> > >
>

Re: move jclouds to the attic?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 <rb...@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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> >

Re: move jclouds to the attic?

[Rich Bowen <rb...@apache.org>]

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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> 

Re: move jclouds to the attic?

[Ignasi Barrera <na...@apache.org>]

Forwarding with the jclouds users list address fixed



On Mon, Jan 30, 2023 at 10:15 AM Ignasi Barrera <na...@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é <jb...@nanthrax.net>
> wrote:
>
>> Fair enough. Thanks Andrew.
>>
>> Regards
>>
>> JB
>>
>> On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <
>> geomacy@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 <ga...@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/
>>
>

Re: move jclouds to the attic?

[Ignasi Barrera <na...@apache.org>]

Forwarding with the jclouds users list address fixed



On Mon, Jan 30, 2023 at 10:15 AM Ignasi Barrera <na...@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é <jb...@nanthrax.net>
> wrote:
>
>> Fair enough. Thanks Andrew.
>>
>> Regards
>>
>> JB
>>
>> On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <
>> geomacy@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 <ga...@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/
>>
>

Re: move jclouds to the attic?

[Ignasi Barrera <na...@apache.org>]

Forwarding with the jclouds users list address fixed



On Mon, Jan 30, 2023 at 10:15 AM Ignasi Barrera <na...@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é <jb...@nanthrax.net>
> wrote:
>
>> Fair enough. Thanks Andrew.
>>
>> Regards
>>
>> JB
>>
>> On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <
>> geomacy@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 <ga...@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/
>>
>

Re: move jclouds to the attic?

[Ignasi Barrera <na...@apache.org>]

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é <jb...@nanthrax.net>
wrote:

> Fair enough. Thanks Andrew.
>
> Regards
>
> JB
>
> On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <
> geomacy@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 <ga...@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/
>

Re: move jclouds to the attic?

[Ignasi Barrera <na...@apache.org>]

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é <jb...@nanthrax.net>
wrote:

> Fair enough. Thanks Andrew.
>
> Regards
>
> JB
>
> On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <
> geomacy@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 <ga...@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/
>

Re: move jclouds to the attic?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Fair enough. Thanks Andrew.

Regards

JB

On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/

Re: move jclouds to the attic?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Fair enough. Thanks Andrew.

Regards

JB

On Sun, Jan 29, 2023 at 9:07 AM Andrew Gaul <ga...@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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/

Re: move jclouds to the attic?

[Andrew Gaul <ga...@apache.org>]

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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/

Re: move jclouds to the attic?

[Andrew Gaul <ga...@apache.org>]

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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/

Re: move jclouds to the attic?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> > > >
> >

Re: move jclouds to the attic?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 <ge...@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é <jb...@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 <ge...@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 <ga...@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/
> > > >
> >