Using time wisely includes not boiling to ocean. Supporting every possible use case, with every provider, in every environment, and with every combination of language and tools, has historically made delivering quality jclouds releases difficult given our limited developer base. Keeping a tighter project scope to concentrate on core use cases is reasonable if people do not volunteer for maintaining the non-core cases.
Listening to users requires actual listening, not just platitudes. We have integrated feedback from many users over the last year, including requests related to your frustrations with Guava. Many users want to deploy older versions of jclouds with newer versions of Guava and addressing deprecations proactively allows this. Granted, we could make different and potentially better decisions about when to intake dependency upgrades to ease backports, although backporting tens of thousands of lines of cleanups was not previously considered. Moving to Java 7 was not an issue taken lightly and we did more outreach for this than any other issue I am aware of, and delayed the breaking change for a significant interval to accommodate any stragglers. Java 7 improves HTTP Expect handling (which I have debugged for users several times), allows larger single-part blobs (not all providers support multi-part upload), allows the filesystem provider to preserve metadata (which affects downstream projects[1]), and has a variety of enhancements that appeal to developers. Maligning this decision as a simple preference for try-with-resources syntactic sugar is incomplete and incorrect. Android compatibility is an interesting possibility although does not align with traditional jclouds use cases. Use of Java 7 does not preclude use of jclouds on Android, rather it requires using newer devices, 25% of which have compatibility today. Given the limited number of Android queries over the years (roughly the same as a marginal provider like CDMI), the lack of any known application in the Google Play Store, and since we have not identified an Android use case (how many users will thumb in 60 character AWS credentials to manage VMs?), why should we let Android dictate the experience of the broader user base? [1] https://github.com/andrewgaul/s3proxy/issues/18#issuecomment-59147262 On Mon, Oct 13, 2014 at 08:21:15AM -0700, Adrian Cole wrote: > OK folks, I'm out for a bit as I have a personal trip and a spike at > work which will prevent me from arguing about try-with-resources for a > while. Two thoughts to part on. > > * I'm pretty sure jclouds wants folks like me to participate. Please > make that easier and less stressful, monotonous, or otherwise WTF. > > When we create long-term branches before identifying any user-pleasing > features, and then don't backport anything, folks like me are > backporting MoreObjects to Objects, or hunting in git history vs > looking at how to fix real problems or realize real features. Please, > find a way to end the "I forked for try-with-resources" madness. Even > if you hate the idea of android, do it to keep your other devs > productive and to stop the bug port gap. Fork when you've found > something meaningfully incompatible. > > * When we started jclouds, it was all about the users. Find them again > > As a project, we should never justify something by saying an account > with 200 followers tweeted it and no-one complained, or some email > that was mobbed by a dev pile-on only had one user say "meh". There's > a real, but solvable engagement problem. Please don't perpetuate this > disconnection. Engage and ask users what they are doing. Ask them to > reply to mail threads. Don't pile-on to user discussion.. allow folks > to reply, and actively nudge users who aren't replying to either reply > or send you text that they reply with. > > Hope this helps, and see you around. > -A -- Andrew Gaul http://gaul.org/
