Using time wisely

[Adrian Cole <ad...@gmail.com>]

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

Re: Using time wisely

[Adrian Cole <ad...@gmail.com>]

On Mon, Oct 20, 2014 at 4:55 PM, Andrew Gaul <ga...@apache.org> wrote:
> 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.
Probably a stretch to suggest that rolling back the "require java 7"
thing == what you are saying up there.

>
> 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.
I think you have listened and acted on some users, perhaps me others.
You probably don't realize how often I am still contacted about
jclouds, and it isn't limited to (and usually isn't) questions about
guava or blobstore. I've also acted as a user at most companies I've
worked at. Guava drift was the primary reason why jclouds couldn't be
considered at netflix. Eventhough I wrote those 3 dns providers, you
could probably delete them. Burnt by guava -> a completely different
project. The latent big fork over java7, MoreObject.ToStringHelper
hasn't proven to be a sound idea, even if it sounded sane at the time.
It is still wasting time, and the folks who's time are wasted are not
solely interested in blobstore. It is those folks who can help address
the users that you might not be speaking to.

> 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.
I think that your idea of scope favors code you choose to work on or
things you've had to work on. There's nothing to say that an optional
provider like filesystem, which only makes sense on a host, to have a
JRE constraint. Moreover, the default http driver is just that.. a
default. Recommendations to use JRE 7 for certain use cases, or
finding a way to isolate the >2GB single-part blob are possible
without changing the language level of all code.

For example, a lot of the things you mention only matter when using
Java's HttpUrlConnection. That's something I don't think I've seen
anyone use at scale recently. I've seen apachhc, netty, etc.
certainly. Switching the entire project language because of a long
argument seems a little extreme.

When you whittle down what's actually at issue, it is stuff you are
personally concerned with, and if you didn't use HttpUrlConnection, a
lot of it goes away. Even if it didn't there are ways besides changing
the project. For example, the long arg could be used reflectively when
the blob is >2GB. I mean if someone is seriously going to upload 2GB
in one shot... using a default http configuration, they can probably
justify one more reflective call. I mean we reflectively hack that
thing for other reasons anyway.

> 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?
I think I know tradition of jclouds, maybe just a little. Regardless,
there's nothing you've brought up that requires all jclouds code to
have made a switch to a language level. Belittling users who request
android don't change that.

>
> [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/

Re: Using time wisely

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

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/