Why are there so many open pull requests on gradle’s github page? It is rather discouraging to have spent time to submit a fix only to see it ignored for over a month with no comments, while active development by the core team continues daily. I see some of them go back something like 2 years. There is no shortage of development effort since I see many many commits per day, but there is something like 40 pull requests. While some of these are apparently related to lack of CLA signing, it appears many of them are not.
(I tried to find an email address to send this compliant to in private, but in the absence of finding one, I am only left with ranting in public…)
Merging pull requests isn’t free. In fact in most cases there’s a significant amount of work required to review, assess, improve and finally merge a pull request. This work takes away from other work, and we have a limited set of resources and a pretty large list of high priority items, like improving Android support, better IDE integration, etc.
We try to spend a bit of time each week on merging pull request, and balance that out with other priorities. Maybe we don’t get the balance exactly right, but if you look at the last few releases they include a significant number of ‘external’ contributions (pull requests). If you think a particular pull request solves an important issue, then make sure it’s been raised in the forum and has a Jira issue attached.
(One thing to be aware of: some of the “many commits per day” are for sponsored development work, where a client sponsors Gradleware to make particular improvements to Gradle. We only do sponsored work on things that we think are a good idea anyway, but sometimes it skews the priorities a little. An example of this is the ongoing C++ development effort.)
Understood – though this effort/investment is part of making something open source, right? If Gradleware wants to encourage an active and lively community, then I would encourage them to respond in a timely fashion to developer contributions – especially when they are connected to jira issues. Otherwise, it will probably lead to no community involvement whatsoever.
btw. On the first page of github pull requests, I see about 8 jira issues being addressed.
I don’t want to suggest that we can’t do things better, but I think I need to defend our recent record of responding to pull requests. We spend a lot of time on this, and it’s an important part of our process. Most of the pull requests > 1 month old have had direct responses from Gradleware, and many of these are not blocked on our side (but some certainly are).
In some cases, we just don’t want to apply the pull request as it stands. Maybe the implementation isn’t great, the test coverage is inadequate, or it solves a use case in a way that we don’t think improves Gradle. We need to make this call to keep the quality high. Sometimes we take the extra time to work with the author to improve the code until it’s ready to apply, but this does take a lot of time: often more time than implementing the fix directly. Finding the right amount of time to dedicate to this is certainly a balancing act.
Thanks for your feedback. You point about building an open source community is well noted, and is not something we blindly ignore. Personally, I’m hopeful that the upcoming Gradle Plugin Portal will help to address some of these issues, by helping to modularise Gradle and making it easier to contribute to the Gradle ‘ecosystem’.