ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Suereth <joshua.suer...@gmail.com>
Subject Re: Roadmap, goals, future of Ivy?
Date Mon, 24 Aug 2015 01:32:20 GMT
Also a note:

For sbt, we've (for at least a year now) maintained our own fork of the
code base where we mrege in patches from master and try to contribute
back.  We are also concerned about the lack of activity and consider any
Ivy bug something we need to own and fix as a project.

On Sun, Aug 23, 2015 at 8:55 PM, Conor MacNeill <conor@apache.org> wrote:

> Stephen & Jaikiran,
>
> Thanks for your emails. I don't think anyone would be offended by your
> comments. They are well founded.
>
> I do think we need fresh blood for the Ivy sub-projects.
>
> Conor
>
> On 24 August 2015 at 04:10, Stephen Haberman <stephen.haberman@gmail.com>
> wrote:
> > Hi Jaikiran,
> >
> > FWIW I've made similar complaints about inactivity on Ivy, and suggested
> > awhile ago that Ivy needs a new group of committers/contributors who are
> > willing/able to put the time into the project.
> >
> > But nothing has happened.
> >
> > Which I found somewhat ironic, because I watched Apache Spark go through
> > the incubation process, and Spark already had an extremely healthy open
> > source community. And yet they were still occasionally lectured about
> "the
> > Apache Way" of nurturing a healthy community/project.
> >
> > Which is fine, totally understood the Apache people were just trying to
> > help Spark's long-term success; but then when I look at projects like
> Ivy,
> > which is extremely widely used (embedded in Gradle, sbt, pants, used
> > standalone via Ant, etc.), but the developer community is basically dead,
> > well, it makes me wonder where the "Apache Way" zealots are and what went
> > wrong.
> >
> > (Ant has a huge user base, but I'd actually assert more new projects are
> > using Ivy, than are using Ant, *but* it's also very likely new project
> > usage of Ivy is primarily via being embedded in Gradle/sbt/etc., and not
> > standalone.)
> >
> > To me there is no harm in admitting when contributors who have done a
> great
> > job over the years, are just busy with new things, and some fresh blood
> is
> > needed.
> >
> > Totally understood you can't just grant commit rights to whoever submits
> a
> > pull request. But it seems like some sort of purposeful effort to steward
> > new committers/loosen the reins a bit would be worthwhile for the long
> term
> > health of the project.
> >
> > Also, I don't mean to offend anyone; we use Ivy extensively at work, and
> it
> > works great. I don't think anyone involved in Ant/Ivy is doing a "bad
> job",
> > I think it's just a matter of recognizing the reality of the community's
> > state, and dispassionately deciding what can be done about it.
> >
> > - Stephen
> >
> >
> > On Sat, Aug 22, 2015 at 11:26 AM, Jaikiran Pai <jai.forums2013@gmail.com
> >
> > wrote:
> >
> >> The past few weeks I've been trying to contribute by fixing some issues
> >> that have been noted in JIRA. I've opened a pull request with a fix a
> while
> >> back[1] and also have asked a few questions about some other issues
> that I
> >> am thinking to work on. However, there has been no response, neither to
> the
> >> pull request nor to the question.
> >>
> >> Is there any public roadmap, goals and future plans for the Ivy
> project? I
> >> would like to continue contributing, but if there's no real plans to
> >> continue development in the project, then I would just end up wasting my
> >> time.
> >>
> >> [1] https://github.com/apache/ant-ivy/pull/7
> >>
> >> -Jaikiran
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message