> Le 6 déc. 2016 à 17:21, Stefan Bodewig <bode...@apache.org> a écrit : > > On 2016-12-05, Jaikiran Pai wrote: > >> I have been following the latest emails on retiring sub projects in >> Ant. I just see a proposal to retire IvyDE (the Eclipse plugin) for >> valid reasons (given the lack of any real activity in there). Given >> this, I would like to understand what the future of Ivy project itself >> is. > > This isn't easy to answer. It looks as if we could manage to gain > momentum again. Looking at the number of people who responded in this > thread, there seems to be enough interest of people willing to get their > hands dirty. > > For now there we don't intend to retire Ivy, but it sure looks pretty > much asleep. > > Honestly I don't think the problem is that nobody knows how to cut a > release, this should be automated mostly anyway and would be extremely > hard to do without access to ASF infrastructure. What we seem to lack is > people who actually know the Ivy code base and have the time to review > patches/develop new features. > > Taking myself as an example I have never looked much at Ivy's code and > have completely ignored all issues over there. My plate is full anyway > and I wouldn't know how to find the time needed to learn the ins and > outs. Of course there is a catch here, if we don't manage to apply > patches we'll never find people who are willing to contribute. > > Ivy may be in use by other projects (I think gradle 3 has moved off of > Ivy, may be wrong
As far as I can tell, Ivy is still a dependency for dependency management: https://github.com/gradle/gradle/blob/master/gradle/dependencies.gradle#L41 https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/dependency-management.gradle#L19 Now to answer to globally to the discussion about Ivy’s future, it is indeed not bright. As pointed, the few people who know the code are still around, so it is not technically dead. But it needs more than that to continue to be maintained. To continue the point made by Stefan, we need people which understand the code, but I think more than providing patches. We need people who code but also can decide when to cut a release, do some ticket triage, give some time to answer to the user mailing list. We are in a weird state here because the bylaws of Apache still enforce the decisions to be taken by people which are not much active. But if some people are willing to contribute and make the Ivy project healthy again, I am sure some of us will make the effort to make the transition work. For instance, if somebody here really want a new release of Ivy happen, there are a lot of stuff which doesn’t require to be a committer: - first it will be great to see a summary of what will be in the release, explain if it will a bug fix release, or a major release, or if it requires to be a release candidate - maybe there is some jira triage to do, is there any pending patch we've missed which could be easily included in the release - test if the release process is still working, if there is anything to fix (I don’t even remember if we have done our first Ivy release while the sources being hosted on git). - we still have trouble to release the doc I think, because there is a mix of svn and git. Probably some work to do here, even maybe suggest a better process - I think building the release artifacts itself doesn’t require much credentials, so anybody could provide some These are just ideas poping up my mind to show that if people are enough motivated, they can make things happen. And obviously, if things work well, credentials will be granted. I think this is the same for IvyDE, but it requires much more effort because the build is broken since we migrated to git, and so the release process has to be reviewed. Too much effort for me. Note though that we have a process to reactivate sub projects, so this is not for life (I kind of hope a reborn, this is the project which made me an Apache committer!). Nicolas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
